* usage of basu as requirement for sd-bus
@ 2022-08-30 7:59 muradm
2022-08-30 9:12 ` Maxime Devos
0 siblings, 1 reply; 5+ messages in thread
From: muradm @ 2022-08-30 7:59 UTC (permalink / raw)
To: guix-devel; +Cc: Maxime Devos, ( <paren@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
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.
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?
Thanks in advance,
muradm
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usage of basu as requirement for sd-bus
2022-08-30 7:59 usage of basu as requirement for sd-bus muradm
@ 2022-08-30 9:12 ` Maxime Devos
2022-08-30 9:13 ` Maxime Devos
2022-08-30 9:27 ` muradm
0 siblings, 2 replies; 5+ messages in thread
From: Maxime Devos @ 2022-08-30 9:12 UTC (permalink / raw)
To: muradm, guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usage of basu as requirement for sd-bus
2022-08-30 9:12 ` Maxime Devos
@ 2022-08-30 9:13 ` Maxime Devos
2022-08-30 9:27 ` muradm
1 sibling, 0 replies; 5+ messages in thread
From: Maxime Devos @ 2022-08-30 9:13 UTC (permalink / raw)
To: muradm, guix-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 257 bytes --]
> (**) 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.
>
Oops I misread the dates -- the latest commit in basu was before the
latest commit in 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usage of basu as requirement for sd-bus
2022-08-30 9:12 ` Maxime Devos
2022-08-30 9:13 ` Maxime Devos
@ 2022-08-30 9:27 ` muradm
2022-08-30 10:03 ` Maxime Devos
1 sibling, 1 reply; 5+ messages in thread
From: muradm @ 2022-08-30 9:27 UTC (permalink / raw)
To: Maxime Devos; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 3776 bytes --]
Maxime Devos <maximedevos@telenet.be> writes:
> [[PGP Signed Part:Undecided]]
>
> 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.
Not necessarily, simple ifdef or alike will silently drop
anticipiated functionality. Software will build without
errors but functionality expected by users might be
missing.
>> 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).
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.
>
> 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.
>
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. 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.
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?
> 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.
>
> [2. OpenPGP public key --- application/pgp-keys;
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]
Thanks in advance,
muradm
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usage of basu as requirement for sd-bus
2022-08-30 9:27 ` muradm
@ 2022-08-30 10:03 ` Maxime Devos
0 siblings, 0 replies; 5+ messages in thread
From: Maxime Devos @ 2022-08-30 10:03 UTC (permalink / raw)
To: muradm; +Cc: guix-devel
[-- Attachment #1.1.1.1: Type: text/plain, Size: 2447 bytes --]
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.
[-- Attachment #1.1.1.2: Type: text/html, Size: 3636 bytes --]
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-08-30 10:29 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-30 7:59 usage of basu as requirement for sd-bus muradm
2022-08-30 9:12 ` Maxime Devos
2022-08-30 9:13 ` Maxime Devos
2022-08-30 9:27 ` muradm
2022-08-30 10:03 ` Maxime Devos
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.