Bug#483962: uuid-runtime: improved description and reconsider priority
Frans Pop
Version: 1.40.8-2
Severity: wishlist
Please consider changing the package description for uuid-runtime to the
following:
<snip>
libuuid generates and parses 128-bit universally unique id's (UUID's). See
RFC 4122 for more information.
This package contains the uuidgen program and the uuidd daemon.
The uuidd daemon is used generate universally unique identifiers (UUIDs),
especially time-based UUID’s, in a secure and guaranteed-unique fashion,
even in the face of large numbers of threads trying to grab UUID’s
running on different CPU’s. It is used by by libuuid as well as the
uuidgen program.
</snip>
Motivation:
The package is currently recommended by the library but from the package
description it is not clear why you'd want to install it or when you
might not need it.
The fact that the package is only recommended means that libuuid-runtime
will *not* be installed on newly installed Debian systems by default
(both debootstrap and Debian Installer do not install recommended
packages).
If that was not the intention, then please consider increasing the
priority to "standard". Colin Watson tells me that for Ubuntu it is
already included in the base system.
Cheers,
FJP
Theodore Tso
- Ted
commit 9aa109c95dd0fc2cbcb0d309ab830d5898e1344b
Author: Theodore Ts'o <ty...@mit.edu>
Date: Mon Jun 2 21:37:06 2008 -0400
debian: Improve uuid-runtime package description
Addresses-Debian-Bug: #483962
Signed-off-by: "Theodore Ts'o" <ty...@mit.edu>
diff --git a/debian/control b/debian/control
index 73e7ac8..c3ceda4 100644
--- a/debian/control
+++ b/debian/control
@@ -95,8 +95,13 @@ Description: universally unique id library
libuuid generates and parses 128-bit universally unique id's (UUID's).
See RFC 4122 for more information.
.
- This package contains the uuidd daemon which is used by libuuid as well as
- the uuidgen program.
+ This package contains the uuidgen program and the uuidd daemon.
+ .
+ The uuidd daemon is used to generate universally unique identifiers (UUIDs),
+ especially time-based UUID’s, in a secure and guaranteed-unique fashion,
+ even in the face of large numbers of threads trying to grab UUID’s
+ running on different CPU’s. It is used by by libuuid as well as the
+ uuidgen program.
Package: libuuid1-udeb
Section: debian-installer
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Frans Pop
> On Tue, Jun 03, 2008 at 10:54:14AM +0200, Frans Pop wrote:
> > Does that mean that the fact uuid-runtime is _not_ installed by
> > default on new Debian systems is deliberate (the second part of the
> > BR)?
>
> Thanks, I didn't notice the second part of the bug report. Hmm. That
> can go either way; there are arguments in both directions. The uuidd
> daemon as designed is not strictly required; it's just that if you are
> going to be generating time-based UUID's at a high rate (which a
> certain commercial Enterprise Resource Planning system does when
> installing its database) without the uuidd daemon, it is possible to
> end up with duplicate UUID's.
Seems to me that can (and should) be solved by making any application that
does require the daemon for that reason depend on uuid-runtime.
> The flip side of it is, first of all, time-based UUID's are not the
> default; random UUID's are [...]
Good. Strong argument for not installing it by default.
> The other potential reason why we might want to install uuid-runtime
> by default is that I moved uuidgen into that package. It makes sense,
> as it *is* a runtime program, and bundling it with either libuuid or
> e2fsprogs probably was less intuitive --- but over the years, some
> people have gotten used to the fact that uuidgen was always present.
> So it has been a bit of a surprise for some folks that uuidgen isn't
> present any more, and it hasn't been obvious to some folk where to
> find it.
That means that it is probably correct to leave it as a recommends so that
uuidgen does not get "lost" on Etch->Lenny upgrades.
But IMO your explanation is support enough for not including it by default
on new installations.
Given that the package has uuid in its name and that uuidgen is clearly
mentioned in the package description, it should not be too hard to find
for people who want it.
Other packages that use uuidgen should just add a dependency. Are you
aware of any that do and that might be missing the dependency because
their maintainers are not aware of the split.
So, my suggestion would be to leave things as they are.
Thanks for the elaborate explanation Ted. This also nicely documents the
decision.
Cheers,
FJP
Theodore Tso
>
> Does that mean that the fact uuid-runtime is _not_ installed by default on
> new Debian systems is deliberate (the second part of the BR)?
Thanks, I didn't notice the second part of the bug report. Hmm. That
can go either way; there are arguments in both directions. The uuidd
daemon as designed is not strictly required; it's just that if you are
going to be generating time-based UUID's at a high rate (which a
certain commercial Enterprise Resource Planning system does when
installing its database) without the uuidd daemon, it is possible to
end up with duplicate UUID's.
The flip side of it is, first of all, time-based UUID's are not the
default; random UUID's are (said commercial ERP uses time-based UUID's
because if you fold, spindle, and mutilate in a certain way such that
the Ethernet MAC address is in the most significant bytes, key
compression means they get stored in the database more efficiently;
and BTW, random UUID's are the default precisely because time-based
UUID's leak the MAC address, which could potentially be a privacy
consideration if they are used e.g. in an Open Office document to
track the original author of a document). Secondly, the collisions
took place when said ERP was generating hundreds of time-based UUID's
per second --- and I know of *no* other application that needs to
generate UUID's of any sort, time-based or otherwise, at those rates.
Finally, while Ubuntu may obtain certification for said ERP in the
near future, it is not at all clear they would support Debian, or that
Debian would be interested in achieving certification for this
commercial/proprietary ERP.
The other potential reason why we might want to install uuid-runtime
by default is that I moved uuidgen into that package. It makes sense,
as it *is* a runtime program, and bundling it with either libuuid or
e2fsprogs probably was less intuitive --- but over the years, some
people have gotten used to the fact that uuidgen was always present.
So it has been a bit of a surprise for some folks that uuidgen isn't
present any more, and it hasn't been obvious to some folk where to
find it.
The bottom line is that I don't have strong feelings one way or the
other about whether uuid-runtime should or shouldn't be a default
installed package. It *is* designed such that it is not mandatory,
since I do have an allergy towards more and more mandatory daemons
running on modern Linux systems, but there are certainly benefits to
having it be installed. What do you think?
- Ted