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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 11, 2015 at 12:58:14PM +0100, Martin Pitt wrote:
> Hello all,
> 
> in case it's useful, this is how we split them in Debian.
> 
> However, is this even a topic for upstream, apart from giving
> recommendations? I. e. do you actually consider putting this kind of
> split into the upstream build system à la "make install-<component>"?
> 
> Lukáš Nykrýn [2015-11-11 11:47 +0100]:
> > Personally I don't think it makes sense to split the package to get a
> > smaller core package. Most of our binaries are just few KBs.
> 
> They are actually fairly big, 100 kB to 1.5 MB for systemd itself. I
> think the main reason for that is that they all statically link
> libsystemd instead of dynamically linking to libsystemd.so.0. Is there
> a particular reason for that?
> 
> > Other aspect would be minimizing external dependencies.
> 
> That is one important reason why we split them in Debian; e. g. the
> machined/nspawn/importd group pulls in a number of rather heavy
> dependencies. udev (including hwdb) is something which you don't need
> in containers, so we split that out too.
> 
> Another reason is to make it easy to enable/disable a particular
> feature (e. g.  libnss-myhostname).
> 
> And then of course the infamous "need to run with sysvinit/upstart",
> which other distros don't need to be concerned about :-)
> 
> > So I suggest following scheme
> 
> FTR, this isn't too far away what we already do in Debian/Ubuntu:
> 
> > systemd
> 
> check
> 
> > systemd-libs
> > systemd-devel
> 
> They are called a bit differently for distro policy, upgrade safety,
> consistency, and multi-arch support reasons; we need separate binary
> packages for every lib*.so. But in spirit, "check".
Yeah, we have systemd-libs and systemd-devel for a long time now.
This follows general Fedora conventions.

> > systemd-journal-remote (so gatewayd,remote,upload)
> 
> Check, we have exactly this package name.
> 
> > systemd-networkd (maybe also with resolved?)
> 
> We currently keep that in the "systemd" package as splitting it out
> now is a bit of an upgrade pain, but we discussed doing this.
> 
> > systemd-machine (machined,nspawn,importd)
> 
> We call that package "systemd-container", but it has exactly those, so
> "check".
I think we (Fedora) should follow this, for inter-distro consistency.


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

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

Zbyszek

PS. I prepared a split of the package on the place, but compling the
rpm on my puny notebook would take too long so I didn't really test it
yet. I'll send it out today for comments.