Re: [Pkg-octave-devel] octave in sid?
Le mardi 20 juin 2017 à 10:02 +0000, Gianfranco Costamagna a écrit :
> Note that this means that we do not plan to remove the Breaks, but
> > rather to update them to match packages versions built against
> > liboctave3v5 (because those will no longer work with octave 4.2).
>
>
> why?
> are you saying that the runtime libraries can't cohexist?
> I don't see a good reason for that not being possible, e.g. I don't
> see dlopens in the code
The point is the following: if a package is compiled against
liboctave3v5, then it will only work with octave 4.0, but not with
octave 4.2. For working with the latter, it needs to be rebuilt against
liboctave4.
So all packages depending on liboctave3v5 will be broken when octave
4.2 is uploaded to unstable, hence the Breaks relationship.
The thing is that liboctave is not a typical library. It contains stuff
related to the octave interpreter, which are closely tied to the octave
binary itself.
> > So basically there is no way we can drop these Breaks, because they
> > are
> > needed for avoiding non-functional partially upgraded systems.
>
>
> h5utils (<= 1.12.1-2.1) [arm64],
> h5utils (<= 1.12.1-2.1+b1) [ppc64el],
> h5utils (<= 1.12.1-2.1+b2) [amd64 armel armhf hurd-i386 i386
> kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc],
>
> this seems really not sane, not maintainable, and breaking every
> debian derivative.
> e.g. something like (<< 1.12.1-2.2) would be more maintenable, even
> if I don't really understand how can stuff break when
> linking dynamically libraries
>
> h5utils is suggesting octave, why should it have such break
> limitation?
Apparently h5utils dropped octave support in version 1.12.1-4. But
previous versions used to depend on liboctave, so the Breaks is
correct.
> The upgrade path needs to be kept until the next stable is out, this
> is why I'm asking to
> drop it for Buster (again, if possible!)
My understanding is that we need to keep the Breaks for a long time,
because suppose that somebody does a partial upgrade from jessie to
stretch then to buster: she could end up with a broken system otherwise
(an old package from jessie depending on liboctave2, therefore not
working with octave 4.0).
Note that octave is not the only software with such a problem. R has a
similar issue (see #861333).
I think an alternative to the Breaks would be to introduce a virtual
package, like octave-api-4.0, provided by the main octave package, and
have octave add-ons depend on it. Then on upgrades of the main octave
package, we would increase the version number in the virtual package,
and that would be equivalent to enforcing the Breaks.
This solution is clearly more elegant, but we did not have the time and
will to implement it so far.
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.
--
.''`. Sébastien Villemot
: :' : Debian Developer
`. `' http://sebastien.villemot.name
`- GPG Key: 4096R/381A7594
Reply to: