Re: possible MBF about Policy 8.2 (Shared library support files)

[Goswin von Brederlow <goswin-v-b@web.de>]

Russ Allbery <rra@debian.org> writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> I mentioned before that there are a lot of packages that violate
>> Policy 8.2 Shared library support files:
>
>>   | If your package contains files whose names do not change with each
>>   | change in the library shared object version, you must not put them
>>   | in the shared library package. Otherwise, several versions of the
>>   | shared library cannot be installed at the same time without
>>   | filename clashes, making upgrades and transitions unnecessarily
>>   | difficult.
>
>> I detected 1063 possible violations with some percentage of false
>> positives. Since those are too many to go through by hand I filtered a
>> bit for the location of the violating files:
>
>> /etc/               : 137 packages
>> /bin/ or /usr/bin   : 285 packages
>> /sbin/ or /usr/sbin/: 47 packages
>
>> Still too many for one go and a huge overlap between the 3 cases so I
>> picked just packages that contained a shared library (as witnessed by
>> a shlibs file in the control.tar.gz) and files in /etc/. I considered
>> any file in /etc/ that does not contain a version in its path or name
>> that would make it distinct from a future SOVERSION in violation of
>> 8.2. I (hopefully) removed all false positives (leaving 126 packages).
>
> One of the potentially tricky parts of this, just to warn, is that Policy
> says just that the files need to change with each change to the SONAME,
> not that this has to be done in any specific way.  So while it's a lot
> cleaner to separate the package (I think), there are cases where we know,
> for some reason, that the upstream is either never going to change SONAME
> ever or that the file will be guaranteed to be obsolete and not included
> in the next revision.
>
> So there may be some cases here where people will say "this really doesn't
> apply to me."
>
> (For example, it probably doesn't really apply to glibc, since the chances
> of it changing SONAMEs are pretty low, although I do appreciate the libc
> maintainers breaking it apart anyway.)

This is true. On its own none of them are a policy violation if you
want to nit-pick. Only when a new SONAME is uploaded with the same
files is the policy really violated.

For that I have 2 things to consider:

1) How sure are you the SONAME never changes? How sure are you the
file will be obsolete in the next SONAME? How sure are you that you
will remember to rename all files on a SONAME change? If there is even
the slightest doubt the name should be changed now to a safe name so
the package is prepared for all eventualities.

With a verry few exceptions (like libc6) the risk of a future
collision is just to big. If that means you have to add a version to
the conffile or split the package now instead of in a year or two that
is regrettable but something I hope can be lived with.


2) Multiarch (are you hating that word yet?) is a release goal for squeeze

With multiarch the library should be installable for multiple
architectures so that (different) binaries from multiple architectures
that depend on it can be installed. E.g. /usr/bin/bar and /usr/bin/baz
both depending on libfoo.

If libfoo contains conffiles then they will give a file collision in
dpkg preventing the installation of more than one architecture. Having
the conffile in libfoo-common (Arch: all) avoids that. Using the arch
tripplet in the path or name avoids it too but should be only used
when conffiles are architecture specific.


Multiarch is actualy the reason libc-bin was created recently as
thereis no libc7 anywhere in sight that would require it. So jump on
the wagon and get your package prepared to meat the challenge of
multiarch.

MfG
        Goswin