[systemd-devel] [packaging] split of systemd package

[Lennart Poettering]

On Wed, 11.11.15 13:38, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
>
> I wonder if this is worth the trouble. The binaries are currently
> fairly big, but do they bring in any external dependencies?
> Maybe we should instead link them dynamically to libsystemd.so?
> This would save some space...

This won't work. We generally try to avoid static variables, but we
have some, for example in log.c to store the log level and
target. Now, you could compile log.c into both libsystemd.so and the
main programs (which is basically what we do), and then make the main
program link against libsystemd.so (which we do not do). In such a
case you'd have two copies of log.c (and thus the static vars) in the
resulting process, and if we set the log level of one, this won't
affect the log level of the other. This is clearly problematic. The
other option of course is to declare all internal APIs exported .so
symbols, but that would mean to commit to a stable API for them (which
is completely out of the question), or to bump the soname on each
release (which is not an option either).

We hence link the internal code into all binaries, and rely on the
linker and compiler to strip as much of that as possible again.

> 
> > We don't have a separate package for that.
> > 
> > > systemd-hwdb
> > 
> > We split out the entire udev, including hwdb. This nicely reduces the
> > footprint in containers and also allows us to use udev with
> > sysvinit/upstart.
> Yeah, that makes a big impact. The only thing that is not clear is
> whether systemd-udevd should be part of this package (a), or part of
> the main package (b). You do (a), but (b) may make sense to run udevd
> without the hardware database. I don't think this is useful except in
> very rare circumstances. Someone brought up the case of an embedded
> device with a custom db... I don't think this is very convincing,
> because in such case you wouldn't ship the text hwdb at all, just
> /etc/udev/hwdb.bin.

THere's no point in shipping the non-binary version of the hwdb. The
hwdb isn't a cache, it's a compiled version of the hwdb, and you don't
the sources around for this.

Lennart

-- 
Lennart Poettering, Red Hat