> > Systemd contains many binaries and depends on a fairly large
number of
> > libraries. Packages which carry systemd units currently have to depend
> > on
> > systemd (through %post, %preun, %postun macros used to install and
> > uninstall
> > systemd units), which grows the dependency tree and increases the size
> > of
> > minimal installs.
> >
> > With this proposal systemd-units subpackages will be split out again:
> > systemd-units
>
> Really not a fan of this, but you are proposing here to reintroduce a
> "-units" package again, and it will container directories and
> binaries, but no actual units? Did I get that right?
>
> Like Kay I think a "systemd-filesystem.rpm" that owns the dirs would
> be a better idea... In particular as the systemctl invocations are all
> suffixed with "|| : > /dev/null 2> /dev/null" (at least the ones
done
> via our macros), and hence should become NOPs if systemd itself is
> missing...
>
systemd-filesystem sounds like a good idea. As for this proposal -- while it
might reduce the size of the buildroot used to build packages depending on
systemd-related macros, what would the effect be on minimal installs --
don't they include systemd anyway?
I agree on the systemd-filesystem side of things, the binaries sounds
like it would be better described as systemd-utils with a provides for
-units.
I don't believe you necessarily need systemd in some container
situations so possibly that's what's being looked at.
Peter