On 30-08-2022 11:27, muradm wrote:
>>
>> 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 th
>
> 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).
This does not look like basu adds additional functionality.

> My intention is not to have something that is not used. Roughly, if
> elogind is not used, why should I have it on my system.
You 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.
> Basically,
>
> 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.
We have package outputs, we can separate the libelogind and busctl from 
the rest. elogind is used, just not in its entirety.
> Btw, how much storage are we talking about when having some
> packages depend on elogind and some on basu? Is it user
> storage or build server/substitute storage concern? 
For basu and elogind itself: 0.9 MiB and 4.2 MiB

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.