Hi,

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).

Possible ways to fix the bug:

1) do not ship a public shared library
There seem to be packages that have a shared lib for multiple
binaries in the same package and no reverse depends. Most likely
the library is not (ment to be) public.

2) Add a version to the name or the path
E.g.: /etc/gtk-2.0/im-multipress.conf

3) Split the package into foo and libfoo or libfooX and libfoo-bin/common
E.g.: eglibc was recently split into libc6 and libc-bin.

Below is the script I used to find candidates and the results filtered
through dd-list. The output filtered for files in /etc/ and full can
be found at:

http://mrvn.homeip.net/policy-8.2/policy-8.2-etc.txt.gz
http://mrvn.homeip.net/policy-8.2/policy-8.2.txt.gz

MfG
Goswin


For a full list of all candidates run
----------------------------------------------------------------------
#!/bin/sh

grep-dctrl "" -n -sFilename dists/sid/*/binary-amd64/Packages
| while read DEB; do
echo >&2 $NUM $DEB
mkdir -p t

dpkg -e $DEB t

if [ -f t/shlibs ]; then
PKG=$(cat t/control | grep-dctrl "" -n -sPackage)
VER=$(cat t/control | grep-dctrl "" -n -sVersion)
MAINT=$(cat t/control | grep-dctrl "" -n -sMaintainer)
SHORT=$(echo $PKG | sed 's/^lib//')
LIB=$(echo $PKG | sed 's/[0-9]*$//')
FILES=$(dpkg -c $DEB
| grep -v " ./usr/share/doc/$PKG/"
| grep -v " ./usr/share/doc/$SHORT/"
| grep -v " ./etc/$PKG/"
| grep -v " ./etc/$SHORT/"
| grep -v " ./usr/share/lintian/overrides/$PKG$"
| grep -v " /$PKG/"
| grep -v " ./lib/.*.so."
| grep -v " ./usr/lib/.*.la$"
| grep -v " ./usr/lib/.*.a$"
| grep "^-" | cut -b 50-)
if [ -n "$FILES" ]; then
echo "Package: $PKG"
echo "Version: $VER"
echo "Maintainer: $MAINT"
echo -n "Libs:"
while read LIB FOO; do
echo -n ", $LIB"
done < t/shlibs | cut -b2-
echo "Files: "
echo "$FILES" | while read LINE; do
echo " $LINE"
done
echo
NUM=$(($NUM + 1))
fi
fi

rm -rf t
done
----------------------------------------------------------------------

----------------------------------------------------------------------
Masayuki Hatta (mhatta) <mhatta@debian.org>
psiconv

Russ Allbery <rra@debian.org>
openldap (U)

Micah Anderson <micah@debian.org>
util-vserver

APT Development Team <deity@lists.debian.org>
apt

Leopold Palomo Avellaneda <leo@alaxarxa.net>
bulmages (U)

Roland Bauerschmidt <rb@debian.org>
openldap (U)

Daniel Baumann <daniel@debian.org>
gnunet (U)
nilfs-tools (U)
open-vm-tools (U)

Daniel Baumann <daniel@lists.debian-maintainers.org>
nilfs-tools

Christian Bayle <bayle@debian.org>
crystalspace (U)
cvsnt (U)

CJ van den Berg <cj@vdbonline.com>
pulseaudio (U)

Vincent Bernat <bernat@debian.org>
libsmi

Armin Berres <trigger+debian@space-based.de>
kdelibs (U)

Michael Biebl <biebl@debian.org>
knetworkmanager
tracker

Julien BLACHE <jblache@debian.org>
sane-backends

Gonéri Le Bouder <goneri@rulezlan.org>
openal-soft (U)

Fathi Boudra <fabo@debian.org>
kdelibs (U)
taskjuggler (U)

John Bovey <jdb@kent.ac.uk>
libnjb

Cyril Brulebois <kibi@debian.org>
openal-soft (U)

Luca Bruno <lethalman88@gmail.com>
apt (U)

Krzysztof Burghardt <krzysztof@burghardt.pl>
libticables

Daniel Burrows <dburrows@debian.org>
apt (U)

Ross Burton <ross@debian.org>
network-manager-openconnect

Michael Casadevall <sonicmctails@gmail.com>
libxfcegui4 (U)

Kanru Chen <koster@debian.org.tw>
gcin

Pierre Chifflier <pollux@debian.org>
libprelude (U)
wzdftpd

CrossWire Packages <pkg-crosswire-devel@lists.alioth.debian.org>
sword

Joost Yervante Damad <andete@debian.org>
wireshark (U)

Debian FreeSmartphone.Org Team <pkg-fso-maint@lists.alioth.debian.org>
fso-usaged

Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
crystalspace
ogre
openal-soft

Debian HA Maintainers <debian-ha-maintainers@lists.alioth.debian.org>
openais-legacy

Debian HPIJS and HPLIP maintainers <pkg-hpijs-devel@lists.alioth.debian.org>
hplip

Debian Install System Team <debian-boot@lists.debian.org>
discover

Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
taskjuggler

Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
mysql-proxy

Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>
nvidia-graphics-drivers
nvidia-graphics-drivers-legacy-173xx
nvidia-graphics-drivers-legacy-71xx
nvidia-graphics-drivers-legacy-96xx

Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
openldap

Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
kdelibs

Debian Scientific Computing Team <pkg-scicomp-devel@lists.alioth.debian.org>
openturns

Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>
bayonne
radiusclient-ng

Debian X Strike Force <debian-x@lists.debian.org>
libcompizconfig
libxvmc

Debian Xfce Maintainers <pkg-xfce-devel@lists.alioth.debian.org>
libxfcegui4
xfce4-panel
xfce4-session

Debian Xiph.org Maintainers <pkg-xiph-maint@lists.alioth.debian.org>
libao

Barry deFreese <bdefreese@debian.org>
crystalspace (U)

Randall Donald <rdonald@debian.org>
nvidia-graphics-drivers (U)
nvidia-graphics-drivers-legacy-173xx (U)
nvidia-graphics-drivers-legacy-71xx (U)
nvidia-graphics-drivers-legacy-96xx (U)

Eric Dorland <eric@debian.org>
openct
opensc

Roland Dreier <rolandd@cisco.com>
libipathverbs
libmthca

Sebastian Dröge <slomo@debian.org>
wildmidi (U)

Dirk Eddelbuettel <edd@debian.org>
ggobi
r-base

Peter Eisentraut <petere@debian.org>
pgpool2

Mattias Ellert <mattias.ellert@fysast.uu.se>
voms

Fglrx packaging team <pkg-fglrx-devel@lists.alioth.debian.org>
fglrx-driver

Sean Finney <seanius@debian.org>
libcompizconfig (U)

Stephen Frost <sfrost@debian.org>
openldap (U)

Bdale Garbee <bdale@gag.com>
amanda

Daniel Glassey <wdg@debian.org>
sword (U)

John Goerzen <jgoerzen@complete.org>
bacula

Stephen Gran <sgran@debian.org>
freeradius

Federico Di Gregorio <fog@debian.org>
ogre (U)

Debian QA Group <packages@qa.debian.org>
htdig
knoda
libiphone
libjconv
libvuurmuur
opencryptoki
radiusclient
synfig
wvstreams

Gudjon I. Gudjonsson <gudjon@gudjon.org>
comedilib

Steinar H. Gunderson <sesse@debian.org>
libgssglue (U)
libtirpc

Philipp Matthias Hahn <pmhahn@debian.org>
audit
ike

Christian Hammers <ch@debian.org>
quagga

Andreas Henriksson <andreas@fatal.se>
rygel (U)

Emmet Hikory <emmet.hikory@gmail.com>
wildmidi

Henrique de Moraes Holschuh <hmh@debian.org>
hplip (U)

Simon Horman <horms@debian.org>
heartbeat
perdition

Simon Huggins <huggie@earth.li>
libxfcegui4 (U)
xfce4-panel (U)
xfce4-session (U)

Mark Hymers <mhy@debian.org>
freeradius (U)

Alberto Gonzalez Iniesta <agi@inittab.org>
kmyfirewall

Jan Janak <jan@iptel.org>
radiusclient-ng (U)

Aurelien Jarno <aurel32@debian.org>
lm-sensors-3

LaMont Jones <lamont@debian.org>
postfix

Guillem Jover <guillem@debian.org>
svgalib

Till Kamppeter <till.kamppeter@gmail.com>
hplip (U)

Bruno "Fuddl" Kleinert <fuddl@tauware.de>
openal-soft (U)

Julian Andres Klode <jak@debian.org>
apt (U)

Michael Koch <konqueror@gmx.de>
ogre (U)

martin f. krafft <madduck@debian.org>
libphidgets

Kilian Krause <kilian@debian.org>
bayonne (U)
radiusclient-ng (U)

Noèl Köthe <noel@debian.org>
garmin-forerunner-tools (U)

Emmanuel Lacour <elacour@home-dn.net>
libnss-mysql-bg

Jeremy Lainé <jeremy.laine@m4x.org>
kdevelop

Torsten Landschoff <torsten@debian.org>
hplip (U)
openldap (U)

Steve Langasek <vorlon@debian.org>
openldap (U)

Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>
sword (U)

Ron Lee <ron@debian.org>
vpb-driver

Faidon Liambotis <paravoid@debian.org>
bayonne (U)

John Lines <john@paladin.demon.co.uk>
plptools

Ana Beatriz Guerrero Lopez <ana@debian.org>
kdelibs (U)

Martin Loschwitz <madkiss@debian.org>
libxfcegui4 (U)
openais-legacy (U)

Ola Lundqvist <opal@debian.org>
ntop
util-vserver (U)

Marc-André Lureau <marcandre.lureau@gmail.com>
rygel (U)

Eugene V. Lyubimkin <jackyf.devel@gmail.com>
proxychains

Debian GNUnet Maintainers <gnunet@lists.debian-maintainers.org>
gnunet

Debian Rygel Maintainers <ah-rygel@debian.org>
rygel

Debian VMware Maintainers <vmware@lists.debian-maintainers.org>
open-vm-tools

Bertrand Marc <beberking@gmail.com>
fglrx-driver (U)

Jonathan Marsden <jmarsden@fastmail.fm>
sword (U)

Christoph Martin <christoph.martin@uni-mainz.de>
socks4-server

Christoph Martin <Christoph.Martin@Uni-Mainz.DE>
socks4-server (U)

Roland Mas <lolando@debian.org>
argyll

TSUCHIYA Masatoshi <tsuchiya@namazu.org>
mecab

Patrick Matthäi <pmatthaei@debian.org>
fglrx-driver (U)
sbnc
tork

Rene Mayrhofer <rmayr@debian.org>
strongswan

Andres Mejia <mcitadel@gmail.com>
openal-soft (U)

Miguel Gea Milvaques <xerakko@debian.org>
bulmages (U)

Steffen Moeller <moeller@debian.org>
voms (U)

Matthijs Mohlmann <matthijs@cacholong.nl>
openldap (U)

Kenshi Muto <kmuto@debian.org>
mlterm

René Mérou <ochominutosdearco@gmail.com>
bulmages

David Nusinow <dnusinow@debian.org>
discover (U)
libxvmc (U)

Sam Hocevar (Debian packages) <sam+deb@zoy.org>
svgalib (U)

Drew Parsons <dparsons@debian.org>
libxvmc (U)

Yves-Alexis Perez <corsac@debian.org>
libxfcegui4 (U)
xfce4-panel (U)
xfce4-session (U)

Christian Perrier <bubulle@debian.org>
apt (U)

Frederic Peters <fpeters@debian.org>
wireshark

Mickael Profeta <profeta@debian.org>
libprelude

Christophe Prud'homme <prudhomm@debian.org>
openturns (U)

Pulseaudio maintenance team <pkg-pulseaudio-devel@lists.alioth.debian.org>
pulseaudio

Mark Purcell <msp@debian.org>
bayonne (U)
hplip (U)
hpoj
radiusclient-ng (U)
taskjuggler (U)

Pau Garcia i Quiles <pgquiles@elpauer.org>
witty

Ganesan Rajagopal <rganesan@debian.org>
ipsec-tools

Thierry Reding <thierry@doppeltgemoppelt.de>
openal-soft (U)

Petter Reinholdtsen <pere@debian.org>
discover (U)

Tomeu BorrÃ*s Riera <tborras@conetxcia.com>
bulmages (U)

Branden Robinson <branden@debian.org>
libxvmc (U)

Emanuele Rocca <ema@debian.org>
libxfcegui4 (U)
xfce4-panel (U)
xfce4-session (U)

Giuseppe Sacco <eppesuig@debian.org>
hylafax

Alexander Sack <asac@debian.org>
connman

Alexander Sack <asac@ubuntu.com>
connman (U)

Anibal Monsalve Salazar <anibal@debian.org>
libgssglue
openais-legacy (U)
pcp (U)

Andres Salomon <dilinger@debian.org>
libxvmc (U)

Otavio Salvador <otavio@debian.org>
apt (U)
discover (U)

Frederik Schüler <fs@debian.org>
openais-legacy (U)

Nathan Scott <nathans@debian.org>
pcp

Raúl Sánchez Siles <rasasi78@gmail.com>
kdelibs (U)

Gustavo Noronha Silva <kov@debian.org>
gksu-polkit

Sjoerd Simons <sjoerd@debian.org>
pulseaudio (U)

Adeodato Simó <dato@net.com.org.es>
libao (U)

Craig Small <csmall@debian.org>
procps

Bradley Smith <bradsmith@debian.org>
libggi
libggigcp
libggimisc
libggiwmh
libgii
libgiigic

Manoj Srivastava <srivasta@debian.org>
libsemanage

Gaudenz Steinlin <gaudenz@debian.org>
discover (U)

Roland Stigge <stigge@antcom.de>
xenomai

Heiko Stuebner <heiko@sntech.de>
fso-usaged (U)

Bryan Sutula <Bryan.Sutula@hp.com>
openhpi

Reinhard Tartler <siretart@tauware.de>
openal-soft (U)

Michael Tautschnig <mt@debian.org>
lnpd

Pino Toscano <pino@kde.org>
kdelibs (U)

Ralf Treinen <treinen@debian.org>
garmin-forerunner-tools
mona

Norbert Tretkowski <nobse@debian.org>
mysql-proxy (U)

Mathieu Trudel <mathieu.tl@gmail.com>
concordance

Andreas Tscharner <andy@vis.ethz.ch>
cvsnt

Modestas Vainius <modestas@vainius.eu>
kdelibs (U)

Wouter Verhelst <wouter@debian.org>
belpic

Michael Vogt <mvo@debian.org>
apt (U)

Sune Vuorela <debian@pusling.com>
kdelibs (U)

Florian Weimer <fw@debian.org>
quagga (U)

Stefano Zacchiroli <zack@debian.org>
gtkmathview

----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, Nov 17 2009, Goswin von Brederlow wrote:

> 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.

> Manoj Srivastava <srivasta@debian.org>
> libsemanage

Split up into libsemanage-common in VCS, build testing in
progress. Shall upload in a couple of hours at most.

manoj
--
The absence of labels [in ECL] is probably a good thing. Cheatham
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org