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. > 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. So I don't think multiarch is a suitable rationale for an MBF here. 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. > 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
