On Fri, 23.01.15 04:41, Peter Robinson (pbrobinson(a)gmail.com) wrote:
> 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.
Which is something I find a really questionable idea btw. There's a
lot of stuff systemd does, and it's naive to believe you can just not
do them and get away with it in a container. Apps need APIs, and
systemd provides quite a few of them, which are unavailable if you
don't run systemd. But it's also mundane things like cleaning up /tmp
from time to time. Or pretty much any non-trivial app probably already
needs more than a single service, in which case you need service
management and stuff. You can of course replicate all that in your
container manager, but in that case you are not writing a container
manager anymore, but a full service and system supervisor like
systemd.
I am pretty sure it would be good idea to emphasize the APIs Fedora
offers as a system to app developers. By not providing them in a
container we are certainly not making things easier for people...
But anyway, I can see that people disagree with this... I am not
convinced though that we should fuck up the packaging of systemd too
badly, just to accomodate for broken ideas...
Lennart
--
Lennart Poettering, Red Hat