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


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

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.
- Drop e2fsprogs from essential. The only critical part, aka non ext2/3
specific, it provides is /sbin/fsck IMHO.

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

Bastian

--
"We have the right to survive!"
"Not by killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5


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

On Mon, Jan 07, 2008 at 01:16:59AM -0800, Steve Langasek wrote:
> 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....

AFAICS libuuid1 just needs groupadd/useradd to create a user and group
'libuuid'.

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 ?

Cheers,
--
Bill.

Imagine a large red swirl here.


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

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

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.

Actually the user is created twice currently: in libuuid1.postinst and
uuid-runtime.postinst.

Ted, could you please eloborate why you need the useradd in
libuuid1.postinst at all?

Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHgoheh7PER70FhVQRAkDUAJ9wP3OfZDnFARUIGQxv9k eLQRNWgQCeKF0W
olLeom/a01bekJgAoBYeHZ0=
=GlAn
-----END PGP SIGNATURE-----

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

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

Cheers,

--
Colin Watson [cjwatson@debian.org]


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

Hi,

I've made some cleanup of the passwd and login dependencies, and
remembered this discussion.

The main change is the move of libpam-modules from Depends to Pre-Depends
for login (which is Essential).
This moves libpam-modules to a virtual Essential package, which is the
reason of this mail (but as mentioned in the earlier thread, I don't think
this may be an issue).

On Mon, Jan 07, 2008 at 01:16:59AM -0800, Steve Langasek wrote:
> 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)
[...]
> 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.

I've removed the versioned dependency of passwd on login (and hence the
dependency)

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

I've kept this one.

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

I've moved the login's dependency on libpam-modules to a Pre-Depends.
Without libpam-modules, login and su will always reject the request.

Best Regards,
--
Nekral


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