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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
