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

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd



On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
> On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:

> So e2fsprogs which is "Essential: yes" depends on libuuid1, so
> libuuid1 is effectively "Essential: yes", right?  So if I add a
> dependency on passwd, it will effectively make passwd "Essential:
> yes", as well, and according to policy I should bring it up for
> comment on debian-policy.  So, I am doing so now.

My mail headers disagree. :)  Is this really meant to be on debian-policy
rather than debian-devel?

> Any objections if I add a dependency on passwd for libuuid1?  The
> aternative would be to roll-my-own useradd/adduser functionality, but that
> would be a real PITA....

I think rolling your own would be wrong no matter what.  If there are
specific reasons why libuuid1 can't depend on passwd, we should address
those instead.

But let's have a look:

Package: passwd
Version: 1:4.0.18.2-1
Depends: libc6 (>= 2.6.1-1), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15), login (>= 970502-1), libpam-modules (>= 0.72-5), debianutils (>= 2.15.2)

$ grep-dctrl -n -FEssential yes -sPre-Depends /var/lib/apt/lists/*sid*Packages \
  | tr ',' '\n' |sed -e's/^ //' | sort -u

coreutils (>= 5.93-1)
e2fslibs (= 1.40.3-1)
initscripts
libacl1 (>= 2.2.11-1)
libblkid1 (>= 1.34-1)
libc6 (>= 2.3.6-6)
libc6 (>= 2.5)
libc6 (>= 2.6-1)
libc6 (>= 2.6.1-1)
libc6 (>= 2.7-1)
libcomerr2 (>= 1.34-1)
libncurses5 (>= 5.4-5)
libncurses5 (>= 5.6+20071006-3)
libpam0g (>= 0.99.7.1)
libpam-runtime (>= 0.76-14)
libselinux1 (>= 2.0.15)
libslang2 (>= 2.0.7-1)
libss2 (>= 1.34-1)
libuuid1
libuuid1 (>= 1.34-1)
sysvinit-utils
sysv-rc (>= 2.86.ds1-1.2) | file-rc (>> 0.7.0)
zlib1g (>= 1:1.2.3.3.dfsg-1)
$

So libc6, libpam0g, and libselinux1 are already Pre-Depends of some
essential package or other, and don't pose a problem here.

login is also Essential: yes, so is only in the list because it's a
versioned dep; but it's a versioned dep on a version older than oldstable,
so we can probably prune that dep from passwd to make the essential set just
a little less tangled.  Anyway, nothing in essential currently depends on
passwd so we know there's no problematic loop here.

debianutils is likewise essential, and the versioned dep is likewise
satisfied by the version in stable (though not in oldstable).  Again the dep
could probably be pruned.

That leaves libpam-modules being pulled in, which is not currently essential
or a pre-dep of any other essential packages.  This is not a spurious
dependency on the part of passwd; actually, I'm left wondering why login has
it as a Depends instead of as a Pre-Depends, since the stock login PAM
config isn't going to work very well without those modules, so login seems
to be failing the requirement to be minimally functional while unpacked but
not configured.

But anyway, let's have a look at what promoting libpam-modules entails.

Package: libpam-modules
Version: 0.99.7.1-5
Depends: libc6 (>= 2.6.1-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15)

Three familiar libraries again, along with libdb4.6.  libdb4.6 itself has no
dependencies other than libc6.

So promoting passwd to a Pre-Depends of an Essential package doesn't
introduce any pre-dependency loops, and the only new packages pulled into
the transitively-Essential set are ones that arguably are supposed to be
there already.

As long as none of the maintainers of other Essential packages have plans to
introduce a dependency on libuuid1 that would turn this into a loop, this
looks ok to me.

(BTW, does anyone want to write an essential-checker to check for those
loops automatically? :)

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


Reply to: