[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#700759: Shared library policy on private libs



On Fri, Feb 22, 2013 at 12:27:18PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > I'm not sure how you've arrived at this conclusion.  Have you overlooked
> > that the shlibs in the ntfs-3g package have been fixed by the maintainer
> > in unstable (as commented in bug #700677)?

> > It still doesn't comply with policy 8.1.  But I think that's a policy
> > bug and that this bug report should be referred over to the policy
> > package; I don't see anything further here that needs the technical
> > committee's involvement.

> You're comfortable with creating a situation where those two packages must
> always be upgraded in lockstep and there's no way to retain the old
> version of the ntfs-3g shared library on disk to allow for partial
> upgrades?  Policy doesn't like this configuration for (IMO) sound reasons.
> It may be fine as a special exception in this case, but I'm not really
> seeing why we would want to generally relax Policy here.

> But we can discuss this over on the Policy list, I suppose.

This isn't the only exception of its kind currently in the archive.
A quick grep-dctrl shows the following examples:

Package: e2fslibs
Provides: libe2p2, libext2fs2

Package: glabels
Provides: libglabels5

Package: gnash-common
Provides: libgnash0, libklash0

Package: slapd
Provides: ldap-server, libslapi-2.4-2
(heh)

Package: tk-table
Provides: libtktable2.9

... along with plenty of other language binding packages which use the same
convention for similar reasons.

(source: grep-dctrl -sPackage,Provides -FProvides -w 'lib.*' -a --not 
-FPackage -r '.*-dev$' -a --not -FPackage -r '^lib.*')

I think these kinds of exceptions should be discouraged quite strongly, but
as the current policy language hasn't eliminated them altogether and there
is precedent, I'd prefer that Policy give more concrete guidance about when,
why, and how such exceptions are tolerable (if they are) rather than leaving
them as floating Policy violations in the archive.

Conversely, if this is too ugly to live in Policy, I don't think it should
be allowed in the archive either.  If that's the way people feel, then this
bug should probably stay with the TC due to the overriding-the-maintainer
aspect; but it hasn't been my impression that the discussion is leaning in
that direction, hence my suggestion that this move to debian-policy.

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

Attachment: signature.asc
Description: Digital signature


Reply to: