Question Does the container SIG have a suggestion, or thoughts, on creating a systemd-sysuers stub rpm, for fedora containers only? What about thoughts on creating stubs if other environment-oriented packages get pulled in?
Background There are some packages that feel like they need to run on traditional hardware, instead of containers. Because of their dependencies, they pull in software that doesn't make sense when run in a container.
The Fedora Minimization team has been working to make and keep fedora, and it's containers, smaller. One of these efforts is to get systemd out of containers whenever possible.[1] As we worked on that, we found that some packages were using systemd-sysusers to create their users, thus pulling in systemd just to create a user. Thus far, our investigation into fixing the sysusers problem [2] [3] everything is pointing that we will have to make some type of stub or alternative package installed only on containers.
Talking about a sysusers stub in our weekly meeting we felt it was best to bring in the container SIG, and broaden the scope.[4] Right now it's just systemd-sysusers, but what about if other packages start pulling in other packages (firmware, kernel, etc..) that don't belong in generic containers.
[1] - https://pagure.io/minimization/issue/2 [2] - https://pagure.io/minimization/issue/13 [3] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6YX6CEFBPU3XVZZEHTN6CBH2F7JDF35N/#L3MXZQXZEA6CK2BG2Z45CLLRMEDTFU5B [4] - https://meetbot-raw.fedoraproject.org/teams/minimization/minimization.2019-09-18-15.01.log.html
I don't have a strong opinion on that but to me the problem comes more on the packages that are using systemd-sysusers to create their users. Is there a benefit to use that ?
Also in the container world users don't make much sense, for example when you run an application in OpenShift you just get a random UID , so a package creating a user is really useful here.
To me this sounds really like a case that is specific to containers, are there some advantages at the distribution level to create a stub package ? If not instead of messing around with the packages we could just provide a layered image that would take care of removing the unwanted dependencies during the build of the container.
@ttomecek , @jcajka do you have a opinion on that ?
I think we should try to fix this properly, by pushing for a stand-alone sysusers binary. I talked to Lennart about this at All Systems Go last weekend, and he seemed open to the idea of fixing the circular dependency issue.
I created https://github.com/systemd/systemd/issues/13653 for this.
That would be great. I agree, fixing that circular dependency would be a win on all accounts.
I want to summarize the systemd discussion that happened on the github issue above. There were two proposed solutions. 1 - reduce the dependencies of libsystemd-shared. According to the discussion, it looked like this would cause installation issues. 2 - Make systemd-sysusers (and systemd-tmpfiles) statically linked. According to the discussion, this would make the package bigger.
I sorta like option number 2. And the thing is, nobody discussed, how much bigger it would make things. That would be an interesting experiment to look at.
Login to comment on this ticket.