Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Michael Biebl]

Am 28.01.20 um 17:27 schrieb Ansgar:
> On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
>> Am 28.01.20 um 14:59 schrieb Ansgar:
>>> I tried linking systemd-{sysusers,tmpfiles} statically against
>>> systemd's private library earlier this month.  It increases the
>>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
>>> systemd that is just one percent).
>>
>> Is that 100K per binary?
> 
> I checked my notes at it was 100 kB per binary: they are 212 kB larger
> (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> systemd 243-8.
> 
> It might be possible to make it a bit smaller if one was to somehow
> link libsystemd0 for functions available there (libsystemd-shared
> currently duplicates those).

Ok, thanks for those numbers
>> More importantly, this requires a downstream patch, and I'm really
>> trying hard to reduce the number of those downstream patches.
> 
> Ack.
> 
>>> If we want to use systemd-{sysusers,tmpfiles} in maintainer scripts to
>>> create system users and/or directories under /var, then I think we
>>> should split it off into a separate package, say systemd-utils, so that
>>> package installation doesn't pull in the entire systemd init (for
>>> containers or other uses that might not require an init).
>>
>> Given that open{sysusers,tmpfiles} are currently packaged, shouldn't we
>> wait how that plays out first?
>> Maybe they are sufficiently well maintained upstream/downstream that
>> they would be an alternative for such a use case.
> 
> I admit not being too enthusiastic about open{sysusers,tmpfiles} and
> would prefer to always use systemd-*, even in minimal environments
> created by debootstrap for buildds or other environments.

Tbh, I haven't looked at open{sysusers,tmpfiles} yet so I can't give any
judgement about their quality.

>> What I'm currently missing, is an overall plan. If the sysusers
>> interface is something we want as distro, there should be a coordinated
>> effort, not every package doing this on its own.
> 
> The current state of shipping systemd-{tmpfiles,sysuser} in systemd is
> probably good enough for experimentation in leaf packages (outside of
> what debootstrap would install in minimal environments) or conditional
> use.

The systemd package is designed in a way that it should be installable
without side-effects. I.e. it should be usable in a context where
systemd is not the active PID 1 (i.e. systemd-sysv is not installed),
which means it could be generally used.
I can commit to keep it that way.

> If we agree to recommend use of systemd-{tmpfiles,sysuser} in Policy,
> then I would prefer if it was possible to split these utilities off
> into a separate binary package.

I wonder if there could be a middle way: Instead of moving the binaries,
I copy them (along with libsystemd-shared) into such a systemd-utils
package. That package would have Conflicts/Replaces: systemd and could
be installed in contexts where the full systemd package is not
available/desirable.
This would have the benefit, that I don't need to worry about the
libsystemd-shared issue and the systemd package would remain unchanged.
I'm not sure if you'd be happy with this approach, since
libsystemd-shared is rather large (2.3M). So the benefit of using this
systemd-utils package over the full systemd package wouldn't be so huge.

Michael



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200130/b9e8fe11/attachment-0001.sig>