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
