Hi Sébastien, Thanks a lot for your reply. 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. > > First, please note that we introduced this Breaks after putting much > thought into it, building on the experience we had with many previous > transitions. This is not something that we have done just for fun or > out of ignorance, and if we were to remove it, problems would appear. I don't doubt that, hence I asked instead of filing bugs :). > 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). > 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). > I think the autopkgtest problems that you mention will disappear when > the Release Team triggers the rebuilds. But feel free to tell us if > this is not the case. You are probably mostly right, except in the CURRENT way the retries of autopkgtests are triggered I believe the right combination of packages from unstable will NOT be found. I fear I have to intervene (yes, I already have a patch against britney2 ready, but I need to test it first). The good side of this is however that I realized that autopkgtesting probably does the wrong thing during most other transitions. I'll have to think about that. Paul [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
Attachment:
signature.asc
Description: OpenPGP digital signature