IIUC, everything using basu also works fine with elogind (*), so the
'status quo' of still using elogind (for old and new) seems harmless
to me (except for size -- basu is smaller).
I don't find the "everything using basu also works fine with elogind"
statement/assumption/guess correct, as per contents of elogind and
basu. See above comment for ifdef thingy.
From the README.md of basu:
The sd-bus library, extracted from systemd. Agreed on thThis does not look like basu adds additional functionality.
Some projects rely on the sd-bus library for DBus support. However not all
systems have systemd or elogind installed. This library provides just sd-bus
(and the `busctl` utility).
My intention is not to have something that is not used. Roughly, ifYou should have it because the alternative (i.e., sometimes using basu and sometimes using elogind) increases disk space usage -- it's all internal, unless there's a bug you shouldn't notice it's using elogind instead of basu unless you're doing "guix edit" or such.
elogind is not used, why should I have it on my system.
Basically,We have package outputs, we can separate the libelogind and busctl from the rest. elogind is used, just not in its entirety.
elogind provides: elogind, loginctl, busctl, libelogind (sd-bus, sd-login ...) ...
basu provides: busctl, libbasu
If basu is enought for package it should dependen on basu IMHO.
So my reason is not directly-storage-only, but dependency which
impacts storage in some or another way.
Btw, how much storage are we talking about when having someFor basu and elogind itself: 0.9 MiB and 4.2 MiB
packages depend on elogind and some on basu? Is it user
storage or build server/substitute storage concern?
For basu and elogind in total: 72.9 MiB and 172.8 MiB.
(See: "guix size").
The latter numbers are a bit misleading, as one of the dependencies is 'shepherd' and 'libgc', which would be installed anyway by other software, and because elogind refers to pkg-config while it probably shouldn't.
On "Is it user storage or build serve/substitute storage
concern": yes. There isn't really a "user / substitute storage"
distinction, unless you count baked nars. But that's just
multiplying the storage by approx. 2 (ignoring deduplication).
Greetings,
Maxime.