On 09/16/2018 10:54 PM, Jörg Frings-Fürst wrote: > Hello Julien, > > > Am Mittwoch, den 12.09.2018, 16:14 +0200 schrieb Julien Cristau: >> Package: libsane1 >> Severity: serious > >> Hi, > >> libsane was renamed to libsane1 for apparently no good >> reason. Renames >> for library packages should be tied to ABI breakage (and associated >> SONAME changes). > > > According to Debian Policy 8.6.2, renaming of the SONAME and the > library package name is possible for non-backwards compatible ABI > changes. > > The SONAME is for a longer time 1: > > $ objdump -p ./libsane.so.1.0.27 | grep SONAME > SONAME libsane.so.1 > > $ objdump -p ./libsane.so.1.0.25 | grep SONAME > SONAME libsane.so.1 > > Between libsane.so.1.0.25 and libsane.so.1.0.27 are some symbols > removed. Therefore the change the library from libsane to libsane1 > are possible.
But the SONAME didn't change here. >> Either there was ABI breakage and the SONAME should be bumped (and >> Provides: libsane would be wrong), or there wasn't and the package >> name >> change ought to be reverted. > > > The changes > > -Breaks: libsane (<<1.0.27-1) > -Replaces: libsane (<<1.0.27-1) > -Pre-Depends: ${misc:Pre-Depends} > +Conflicts: libsane (<< 1.0.27-1~) > +Replaces: libsane (<< 1.0.27-1~) > +Provides: libsane (= ${binary:Version}) > > were requested by Jeremy Bicha and taken over after consultation with > my mentor. > You can't have it both ways. Either 1.0.27 is not backwards-compatible with the old libsane, and so you can't Provide it (Provides is a statement of compatibility). Or they're compatible, and the package name shouldn't have changed. It's one or the other, it can't be backwards-incompatible and compatible at the same time. I didn't look at it, and would prefer not to have to, so I don't know which it is, but your statements contradict themselves so they're not really giving information one way or the other. Cheers, Julien