On 05/03/2024 9:22 pm, Vincent Lefevre wrote:
On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.
So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.
Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.
This is not correct. The majority of the packages installed by the
installer are in fact installed via tasksel, and it does install
"Recommends:". The command is there:
https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930.
However it's true that some packages are installed before that, at the
debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".
But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a few days ago, which pulled uuid-runtime.
Looking at some install logs, I can confirm that libuuid1 is installed
by debootstrap (as a dependency of e2fsporogs), and that explains why
uuid-runtime is not installed.
