This is causing docker container images to require systemd and in turn other parts of the OS that will never be used within a container.
In the devel mail list conversation on this subject, Lennart Poettering points out
"Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place..."
I would like to open a bugzilla to remove the systemd requires from all packages that currently add it.
As we move forward into a container world, some of the packages assumptions involving installing an application into a server/desktop might be changing to containers.
The main reason I want systemd and friends out of containers is size, and if there is a security vulnerability in any package that gets installed into a container, then we need to recreate the container, less packages means potentially less rebuilds.
Just removing deps. seems like a bad idea, basically assuming stuff will work in all cases. The first thing that was brought up is if systemd isn't installed, what will provide it's FS directories? The next thing that was brought up is that these deps. are used for transaction ordering, so without them we could randomly hit problems where some things are installed before systemd and their %post then silently doesn't work.
Why can't you have something explicit, like a fakesystemd package? We'd also be open to changing the deps. people should use in policy (Eg. require systemctl-post, then the fake package only needs to provide that).
I think some of the directories could probably be moved to the filesystem package.
filesystem
I don't think a 'fakesystemd' really helps (except for in the transaction ordering), because the packages being "lied to" have no idea how much is really faked.
Is this a case where we could use the new rpm soft dependencies?
Sure, that was suggested as a workaround. But the larger point was that it was unknown how many such workarounds would be needed, and removing deps. just because it seemed to work in one or two cases wasn't a great idea.
But a known set of packages being lied to in a known/observable way is different (better!) than an unknown set of packages being lied to in a number of ways.
Let's say you have:
{{{ systemd rando-daemon [... another 7 daemons ] bash zsh [... 30 other packages ] }}}
...so if we just remove the systemd package and the requires in the dameons we are altering 9 packages, but lying to 40 about the transaction requirements/etc. If someone comes along afterwards and wants to debug something or know "what was affected, what problems might I have to look for, etc. etc." ... tough the data is gone, the transactions look fine to any depsolver and can't show anything.
If we create a fakesystemd, we are "altering" only one package and at worst we are lying to 8. It could also easily be thought of as not lying in this case, and just having to be aware of two providers (like requiring MTA and not relying on getting postfix). If someone comes along after and wants to know "what was affected, what problems do I look for, etc." ... then they'll see fakesystemd being installed in the transaction, or yum provides systemd-post (or whatever) will show fakesystemd.
This kind of keeps the data around, but only if you know to look for it. And while I can see cases where it'll be better to have something to help debugging ... I can also see cases where it'll just confuse everything more.
One possibility is replacing these systemd Requires with !OrderWithRequires, which does not introduce an actual dependency on the package, but is considered in transaction ordering as if it were a require when both packages are present in transaction. Which AFAICS is exactly the desired semantics here.
!OrderWithRequires has been in rpm since 4.9.0 so its already usable in all Fedora current versions + RHEL >= 7.
Yeh, changing to use OrderWithRequires should workaround that problem. And moving files/dirs. to filesystem should workaround that problem ... although both would still be mostly invisible, and there maybe other problems. Most of the FPC are heavily in favour of creating a fake package, instead, if that's possible.
Dan is there a big problem with creating a fakesystemd package for docker/container usage? If not can you work with systemd guys to come up with a virtual provide for post, which should get through FPC fairly quickly/easily.
Dan
Solely for the purpose of satisfying the BuildRequires, Requires on 'systemd-units' [initscript frammage is still present in backporting], I had cobbled together this package to use for build / analytic purposes ftp://ftp.owlriver.com/pub/mirror/ORC/dummy-systemd-units/
It satisfies 'Providing' systemd-units , so my analytic tools can help solve some build loop and closure issues. You may find it more general and portable than messing with the TransactionSet order via 'OrderWithRequires'
Did anything ever happen here? I know that the whole fakesystemd thing turned into a mess, but I don't recall how any of this was resolved, or if the committee still needs to act on something.
I want to split out a part of systemd (into systemd-tools, or systemd-units, or something) which would be enough to satisfy the post/postun/preun macros and reduce the dependency footprint somewhat. I hope to submit something working this weekend.
Well, I saw the discussion on devel@ but it doesn't appear to be going well. Not sure what's to become of this if there's so much objection. We do still have the OrderWithRequires: thing if it would help.
What kind of information and from whom do you need?
Well, we're waiting for something to happen that we can act on. I see that there is considerable dissent about the proposed solution, and I'm not sure what FPC itself can do here.
So the information we need is, basically, a draft or a proposal or something upon which we can vote. Else I can just go ahead and close this ticket and you can either reopen it or just open a new one if you have a proposal for us to consider.
I guess I'll go ahead and close this as I suggested a month ago. If someone wishes to provide a draft or something upon which the committee can vote, please feel free to reopen this ticket or open a new one.
The resolution is right. I forgot to update the status here after the FESCo vote. For the sake of whoever didn't follow the discussion there: splitting a subpackage to reduce dependencies was rejected, so everything which runs systemctl or other systemd tools in rpm scripts has to require systemd.
Login to comment on this ticket.