Re: usage of basu as requirement for sd-bus

[Maxime Devos]

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

(and the `busctl` utility).

systems have systemd or elogind installed. This library provides just sd-bus

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,


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.

elogind provides: elogind, loginctl, busctl, libelogind (sd-bus, sd-login ...) ...

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





Greetings,
Maxime.

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

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature