[systemd-devel] [packaging] split of systemd package
poma
pomidorabelisima at gmail.com
Wed Nov 11 15:23:29 PST 2015
On 11.11.2015 12:58, 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-check"
+1
>> 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.
>
> Martin
>
More information about the systemd-devel
mailing list