Re: possible MBF about Policy 8.2 (Shared library support files)
Steve Langasek <vorlon@debian.org> writes:
> On Thu, Nov 19, 2009 at 05:41:11AM +0100, Goswin von Brederlow wrote:
>> >> 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).
>
>> 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.
>
> In the case of certain libraries: *very* sure. If you aren't sure which
> ones are sure, then I think a mass bugfiling is premature.
I have no way of knowing which sources will be sure to never change
the soname. That is something maintainer might and upstream
should know. My best guess would be to check if the soname already
changed once. But that would still catch e.g. libc6, which we assume
won't change again. If anyone can suggest something better please
speak up.
>> 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.
>
> The present aim for dpkg multiarch support in squeeze is to allow reference
> counting of conffiles provided by multiarch packages, precisely so that we
> don't have to have gratuitous splits of packages for conffiles that can
> reasonably be shared between the libraries on multiple architectures.
> Furthermore, in the event that a conffile *can't* reasonably be shared
> between architectures, it's at least as appropriate for the path of the
> conffile to be qualified with the *architecture*, *instead of* with the
> version.
The multiarch specs are unclear on this:
| Debian/Ubuntu policy already states that files whose names do not
| change with each soname change should not be included in the
| shared library package; so in general it is already wrong to ship
| config files and data files in a shared library package, though
| the practical impact of this varies. (For instance, the soname of
| glibc is not expected to change any time in the future, so the
| libc6 package currently unapologetically ships helper binaries,
| config files, and man pages in the shared library package.)
| However, /usr/share/doc/<package> is expected to be provided by
| every package installed on the system, so a general solution is
| needed for multiarch packages that must be co-installable while
| shipping architecture-independent files.
This can easily be read that only for /usr/share/doc/<package> a
general solution is to be provided. (And the libc6 example is
partially outdated)
It goes on:
| In addition, dpkg will implement an internal checksum database
| for files it installs, and reference counting for files shared by
| multiarch packages. Multiarch packages with differing versions of
| any file will also be treated as declaring reciprocal Breaks.
This can be read that a package of one arch can never have a file
conflict with the same of another arch. Any overwrite errors will just
be reference counted. I would not want /usr/bin/foo reference counted
if it is contained in libfoo and I would hope only identical files
will be allowed.
So please clarify this in the specs. What files are allowed to be
shared and what other criteria must those file met?
> So I don't think multiarch is a suitable rationale for an MBF here.
No, just another incentive and a plea to fix it in a way that
simplifies multiarch too.
> And as for soname transitions: frankly, conffiles are much less of a
> problem (nowadays, thanks to Replaces: working correctly) than non-conffile
> config files, which your MBF appears not to address at all. Non-conffile
> config files in shared library packages are incredibly bad, because there's
> no right way to purge the shared lib package in that case.
Should policy be changed so that using Replaces is allowed? Does that
leave the conffile behind when removing the replacing library while
keeping the replaced one? What if the replaced library gets updated
and has a changed conffile?
To check for non-conffile config files one would have to install every
single package and then check if it created any files. That is a lot
harder to do.
>> 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.
>
> libc-bin was split because of *binaries* that need to be shared between
> architectures, not because of conffiles. Moving the conffiles to libc-bin
> was a reasonable thing to do given that a split was already happening, but
> absent the need for such a -bin package, I don't think conffiles in shared
> lib packages are a serious issue. Only when the soname changes and the
> conffile does not do we have a policy violation, and I don't consider it
> appropriate to make library maintainers do extra work outside of an actual
> library transition to satisfy this additional requirement.
My initial mail gave the number for packages with binaries too:
/bin/ or /usr/bin : 285 packages
/sbin/ or /usr/sbin/: 47 packages
Are those serious enough to file bugs even without an actual soname
transition? Note that 67 of the packages with conffiles also contain
binaries. That is about half of them.
MfG
Goswin
Reply to: