[Pkg-octave-devel] octave in sid?

[Sébastien Villemot]

Le mardi 20 juin 2017 à 11:38 +0000, Gianfranco Costamagna a écrit :
> I hope this clarifies things for you. If you want to work on this
> > virtual API package solution within the Debian Octave Group, you are
> > more than welcome.
> 
> it does, thanks!
> 
> so you want me to implement something like this in reverse-dependencies?
> 
> OCTAVE_VERSION=$(shell dpkg-query --show --showformat='$${source:Upstream-Version}' octave | cut -f1,2 -d.)
> 
> override_dh_gencontrol:
> dh_gencontrol -- \
> -Voctave:Version=$(OCTAVE_VERSION) -Voctave:nextMajor=$(OCTAVE_VERSION).z
> 
> and then, runtime dependency
> octave (>= ${octave:Version}),
> 
> octave (<< ${octave:nextMajor}),
> 
> this should do the trick, and force a full rebuild each time a new octave is uploaded.
> 
> does this sound feasible?
> 
> 
> also, the answer in [1] looks sane
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333#86
> 
> what do you think?
> 
> we could implement this while transitioning the packages to unstable, to avoid useless work for builders,
> if we agree on the implementation, of course

The implementation that I have is mind is slightly different. It would
not go through a versioned depends on octave, but through a virtual
package, like octave-api-XXX. The idea is that the XXX is increased
between major octave releases. More precisely, we would have:

- octave 4.0.*: "Provides: octave-api-4.0"
- octave 4.2.*: "Provides: octave-api-4.2"
- octave-addon built against octave 4.0.*: "Depends: octave-api-4.0"
- octave-addon built against octave 4.2.*: "Depends: octave-api-4.2"

Hence, an octave addon built against octave 4.0 will not be
coinstallable with octave 4.2 (because the latter won't provide octave-
api-4.0).

Then we need to devise a mechanism so that octave addons automatically
depend on the correct virtual API package. For packages using our
helper octave-pkg-dev, this can be implemented straightforwardly in
that helper. For other packages, we have to think how to do it.

Note that if we introduce this mechanism now, it will become useful for
the octave 4.2 -> 4.4 transition. For the 4.0 -> 4.2, we still need to
rely on older means (i.e. the Breaks).


However, I'm wondering if instead all this stuff, we cannot begin by
trying again to add "Breaks: liboctave3v5" in octave 4.2 (instead of
the long list of Breaks). That would be the most elegant solution. In
the past, this was not possible because of #671711. But even with this
bug fixed, there was still a problem (see octave 4.0.0-3 changelog
entry).

Now that the octave trigger will be of the -noawait type (see commit
3cf8b78ff4 in octave git repository), I am wondering if it could not be
working this time. I have to admit that I don't remember exactly why
the "Breaks: liboctave2" did not work for the previous transition, so
I'm not sure it will work this time.  Anyways, I am willing to give it
a try. 

Any thoughts?

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://sebastien.villemot.name
  `-      GPG Key: 4096R/381A7594