[systemd-devel] [packaging] split of systemd package
zbyszek at in.waw.pl
Wed Nov 11 22:39:07 PST 2015
On Thu, Nov 12, 2015 at 06:13:32AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> 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".
> > > 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".
> > > systemd-firstboot (firstboot,sysusers?,factory stuff?)
> > 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, after removing a bunch of stuff, hwdb stuff becomes even more
> I prepared a package for rawhide with [1,2] the following subpackages:
> systemd-journal-remote (remote, upload, gatewayd)
> systemd-container (nspawn, machinectl, machined, importd, pull, var-lib-machines.mount)
> systemd-udev (udevd, udevadm, udev rules, hwdb).
> The first two are uncontroversial (systemd-journal-remote already existed
> as systemd-journal-gateway for a long time).
> The last is somewhat controversial: while people seem to agree about the split,
> it's not necessary clear whether udevd should be in the subpackage or not.
> I went with "yes", to see how that works out. I think this makes more
> sense this way, but maybe not.
>  http://in.waw.pl/git/fedora-systemd/
>  https://copr.fedoraproject.org/coprs/zbyszek/systemd/build/138959/
Installed size of systemd-udev is 6.5MB, systemd-container is 3.5MB,
systemd is 19MB, so the gain is modest. We also lose some dependencies.
More information about the systemd-devel