Re: usage of basu as requirement for sd-bus

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2432 bytes --]


On 30-08-2022 09:59, muradm wrote:
>
> Hello,
>
> basu is sd-bus library extracted from systemd.
>
> Currently, there are two packages depending on it,
> which are mako and grimshot.
>
> In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859,
> I suggest switching xdg-desktop-portal-wlr to basu.
>
> In very same issue, Maxime asks to discuss switching
> _all_ dependents of elogind to basu.
>
> [1] Some elogind dependents, like wireplumber, as per
> code depends on sd-login.h also in module-logind.c.
> While I have wireplumber-without-elogind locally,
> I don't propose switching it basu, because someone
> may want module-logind.c to work.
>
> [2] Currently there are 1461 packages depend on elogind.
> First, all of them should be analyzed if they do use
> sd-bus only, those can be switched to basu. Then
> those using more than sd-bus should be analyzed if
> elogind is missing would their functionality be hurt.
If these problems are like [1], then IIUC these problems would manifest 
as build errors. Checking for build errors is relatively simple by 
pushing to a separate branch first, evaluating it on ci.guix.gnu.org and 
checking for new build failures.
> Because of [1] and [2], I find it not feasible/not
> possible to blindly switch _all_ dependents from
> elogind to basu.
>
> Do I miss anything else here? 

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

As far as I know, the benefit of 'basu' is using less storage (**).  If 
most dependents are switched from elogind to basu, then this benefit can 
be fulfilled. But if we just do a mix of elogind and basu, then we have 
both elogind and basu in the store, _increasing_ the storage footprint 
instead of lowering, which is the opposite of the goal of lowering 
storage usage.

As such, assuming that lowering the storage footprint was your reason 
for switching to basu, I think we should either try switching _all_ 
packages to basu or keep using elogind and add elogind instead of basu 
to new dependents.

Greetings,
Maxime

(*) This is an unverified guess. If disproved, my reasoning becomes a 
lot weaker.
(**) This is just a guess about what your goal was, maybe you had a 
different reason in mind. E.g., basu seems to be more active than elogind.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]