FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-07-2008, 07:23 AM
Theodore Tso
 
Default Bug#459403: libuuid1: missing depends on non-essential package passwd

On Sun, Jan 06, 2008 at 10:37:03AM +0100, Julien Cristau wrote:
>
> the libuuid1 postinst contains:
> groupadd -f -K GID_MIN=1 -K GID_MAX=999 libuuid
> if ! grep -q libuuid /etc/passwd; then
> useradd -d /var/lib/libuuid -K UID_MIN=1 -K UID_MAX=499 -g libuuid libuuid
> fi
> mkdir -p /var/lib/libuuid
> chown libuuid:libuuid /var/lib/libuuid
> chmod 2775 /var/lib/libuuid
>
> The groupadd and useradd commands come from passwd, which is not
> Essential: yes, so a Depends is needed.
>
> Moreover, the postinst succeeds even if any of these commands fail,
> because 'set -e' is missing at the top of the script.

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

Thanks, regards,

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-07-2008, 08:16 AM
Steve Langasek
 
Default 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 ',' '
' |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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-07-2008, 04:30 PM
Kurt Roeckx
 
Default Bug#459403: libuuid1: missing depends on non-essential package passwd

On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso 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

It's not because an essential package Depends on something that that
should also be set to essential. The clasical example is libc6. Alot
of the essential package Depend on it but libc6 is not, and should not,
be essential itself.

But I think that packages which are essential that need a user/group
should get a static one in base-passwd which is essential.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-12-2008, 03:44 AM
Theodore Tso
 
Default Bug#459403: libuuid1: missing depends on non-essential package passwd

On Mon, Jan 07, 2008 at 11:34:07AM +0100, Bastian Blank wrote:
> On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
> > So, I am doing so now. 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....
>
> There are several other possibilities:
> - Move the user creation. It is necessary for uuid-runtime (uuidd), not
> libuuid.

It's actually needed in libuuid, because one of the modes how it can be
used is a program can be setgid libuuid. If so, then when it calls
libuuid, it can optionally save the clock sequence number in
/var/lib/libuuid, and to detect circumstances when the clock goes
backwards. This guarantees that uniqueness, and makes the UUID
generation compliant with RFC 4122. Without libuuid being setgid, or
without the uuidd package installed, the time-based UUID will
*probably* be unique, but if the time gets reset, and you get
very. Very unlucky, or if you have multiple SMP threads generating
huge numbers of time-based UUID's, you could generate duplicate
UUID's.

> What is the reason for this deamon anyway? It linearises the requests
> and limits the amount of available uuids.

So there are some programs that like to use time-based UUID's because
they tend to sort much better (particularly if you byte-reverse the
UUID) when they are used as keys in a database. One such program
generates a *huge* number of them while initializing its application
database. It does so in multiple threads and multiple processes
running in parallel, and it was running into problems because it could
end up generating duplicate UUID's.

The uuidd linearises the requests, yes, but in a very clever way where
each particular thread can request a block of UUID's (with contiguous
times) so it actually allows a much, MUCH larger number of UUID's to
be generated, with *significantly* less CPU overhead. I know of only
one application program that generates this many UUID's (as in tens of
thousands per second). Unless you use this application, it's
relatively unlikely that you need it; however, it is a matter of
correctness as well --- if you want to guarantee uniqueness on an SMP
system, and guarantee uniqueness in the face of an unreliable clock
that might go backwards, implementing the requirements of RFC 4122,
it's necessary. By default though most applications use random
UUID's, for which none of this rigamarole is necessary.

So without uuidd installed, the amount of time to generate 100,000
UUID's is 3.2 seconds. With uuidd installed, the amount of time to
generate 100,000 UUID's drops down to 0.091 seconds.

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-12-2008, 10:41 AM
Steve Langasek
 
Default Bug#459403: libuuid1: missing depends on non-essential package passwd

On Sat, Jan 12, 2008 at 11:33:23AM +0000, Colin Watson wrote:
> On Mon, Jan 07, 2008 at 12:39:30PM +0100, Bill Allombert wrote:
> > Since libuuid1 is essential, every system will end up with a libuuid
> > user/group, so why not just add it to base-passwd instead of creating it
> > dynamically ?

> In general I want to avoid almost all further creation of global static
> IDs. The last exception I made was when the installer needed a group
> with a static ID to exist so that it could hardcode its GID in
> /etc/fstab. Global static IDs are difficult to maintain, complicate
> partial upgrades, require user interaction (this should be overhauled,
> admittedly, but nevertheless), and have a very limited available space.

> I don't think "but we don't want to make adduser Priority: required" is
> a good enough reason to add global static IDs; and passwd doesn't need
> to be made Essential just because an Essential package depends on it
> (Essential isn't closed under dependency).

The use case here was that passwd would be a dependency of a pre-dependency
of an essential package, which does promote it into the effective essential
set.

--
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
 
Old 01-16-2008, 08:49 PM
Theodore Tso
 
Default Bug#459403: libuuid1: missing depends on non-essential package passwd

On Sat, Jan 12, 2008 at 03:41:01AM -0800, Steve Langasek wrote:
> > I don't think "but we don't want to make adduser Priority: required" is
> > a good enough reason to add global static IDs; and passwd doesn't need
> > to be made Essential just because an Essential package depends on it
> > (Essential isn't closed under dependency).
>
> The use case here was that passwd would be a dependency of a pre-dependency
> of an essential package, which does promote it into the effective essential
> set.

Well, I'm happy to make a request for a static ID, or not; do we have
a consensus here whether I should do this?

- Ted


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

Thread Tools




All times are GMT. The time now is 08:08 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org