Hi Paul, Le mercredi 03 octobre 2018 à 20:19 +0200, Paul Gevers a écrit : > On 02-10-18 22:52, Sébastien Villemot wrote: > > > What I noticed is Breaks: liboctave3v5, liboctave4, liboctave5 in the > > > octave binary package. Is this really needed? If so, do you care to > > > explain? It seems to defeat on of the purposes of having shared > > > libraries with different package names when the soname is bumped, as > > > they are now not co-installable if you install octave. > > Basically, the problem is that, for example, liboctave5 is not > > functional with octave 4.4.1 (which ships liboctave6). > > > > Without the Breaks relationship, it would be possible to install an > > add-on, say octave-optim, compiled against liboctave5, while octave > > itself would be at 4.4.1-2. Such a combination does not work, octave- > > optim will crash at runtime. The Breaks is there to prevent such a > > broken partial upgrade, and to make sure that the user upgrades to the > > version of octave-optim recompiled against liboctave6. > > Which sounds to me that shipping a separate library package which > changes package name on each soname bump rather useless. It seems the > first paragraph of policy 8.1 [1] is not applicable: "This allows > several versions of the shared library to be installed at the same time, > allowing installation of the new version of the shared library without > immediately breaking binaries that depend on the old version". Hence, > one could argue that you don't need to rename the library package every > time (not sure if this would be considered appropriate though). Indeed an alternative solution would be to distribute the shared library within the main octave package, and have it Provide a virtual ABI package, on which add-ons would depend. In practice the only change would be that we would have one less binary package (the shared library). But we would still need to go through transitions, since that would not magically avoid the ABI breaks. This solution would make sense, but its benefits are rather tiny, so I'm not sure it's worth it to implement now. Maybe we could do that for the next transition (keeping in mind that we would also have to adapt our tooling, especially dh-octave, so it's not a zero cost move). > > Maybe there is a better solution to this problem than a Breaks, but we > > have not found it so far. And actually the Breaks has worked pretty > > well for previous transitions, so I don't see why it should not be the > > case this time. > > Well, I think it achieves your goal, but what actually breaks is not the > liboctave<n-1> package, but all the packages build against > liboctave<n-1>. I see how that will become a nightmare to maintain > though. (The migration software, britney2, would do the right thing if > you would add those breaks). We used to do precisely that, i.e. adding the Breaks with respect to each broken binary package. This quickly turned into a nightmare, in particular because binary versions of packages are not necessarily the same across architectures (because of binNMUs). Also, this does not play nice with derivative distributions, who may have slightly different version numbers. Thanks for your feedback, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part