[Pkg-octave-devel] octave in sid?

[Gianfranco Costamagna]

Hello Sébastien!
thanks for the quick answer!


>[cc'ing the pkg-octave-devel list]


thanks for that! I'm not sure I have permissions to write there :)

>Currently the plan is to upload Octave 4.2 in unstable as soon as the
>Release team permits (we are going to request a transition slot).


that sounds awesome!
>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
>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?

I admit, I'm sure you know how to deal with your package, but over the years, this is the first package behaving like this
for upgrade paths, and it seems a real mess and pain to maintain.
What happens if Release Team binNMUs the package?

https://buildd.debian.org/status/fetch.php?pkg=h5utils&arch=amd64&ver=1.12.1-6%2Bb1&stamp=1480647406&raw=0

I don't even see octave dragged as build-dependency, so I'm pretty sure that breaks is just useless.


Package: liboctave3v5
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: liboctave3
Replaces: liboctave3
Multi-Arch: same


same here:
Pre-Depends can be safely dropped,

Conflicts+Replaces too.
Unless you say that runtime libraries can't coexist of course

If the rationale for this list was # 671711

I guess we can drop them.

(I'm probably missing something obvious here, but I would like to understand more about
octave, and try to help in simplify the packaging, whenever possible)

please point me to bugs or git commits to understand more the issue (if still an issue, of course).

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!)

G.