Spec URL: http://vpavlin.fedorapeople.org/fakesystemd/fakesystemd.spec SRPM URL: http://vpavlin.fedorapeople.org/fakesystemd/fakesystemd-1-15.fc20.src.rpm Description: fakesystemd is a minimal Docker-specific package to satisfy systemd Provides: without installing systemd in Docker images. It is intended strictly for use in Docker images/containers. It doesn't provide any functionality from systemd package - it only contains few important directories and files. fakesystemd is definitely not applicable for full bootable operation system. If possible, it shouldn't be shipped in primary repo and should be available only for building (Docker) images. To install real systemd in the image you need to run yum swap command in this form: yum swap -- remove fakesystemd -- install systemd systemd-libs Fedora Account System Username: vpavlin
> If possible, it shouldn't be shipped in primary repo and should be available only for building (Docker) images. That's not currently possible. Maybe in the future. We'll need to do some sanity checking to make sure no installs pull this in instead of the real systemd by accident.
I've got some pendantic things to clear up first. 1. Please make the summary shorter and the description longer, including a gigantic warning not to install on a real system. And the summary shouldn't end in a period. (I told you this was pedantic -- sorry!) 2. License says "GPL+", but no actual license text is included. Since this is by nature minimal, what about using a much simpler license (like MIT -- maybe https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT#Modern_Style_without_sublicense_.28Unicode.29) and including the text directly in macros.systemd? 3. Since it conflicts with systemd, needs an explicit "Conflicts: systemd" 4. Copy in %prep stage is unnecessary (and in fact since you refer to %{SOURCE0} directly later, it's not even doing anything 5. In %install stage, I think the big mkdir would be much easier to read and maintain in a loop, like: for dir in systemd/system systemd/user tmpfiles.d sysctl.d modules-load.d binfmt.d udev/rules.d do mkdir -p %{buildroot}%{_sysconfdir}/${dir} done for dir in system-generators user-generators system-preset user-preset system-shutdown system-sleep catalog ntp-units.d do mkdir -p %{buildroot}%{_prefix}/lib/systemd/${dir} done for dir in tmpfiles.d sysctl.d sysctl.d modules-load.d binfmt.d do mkdir -p %{buildroot}%{_prefix}/lib/${dir} done mkdir -p %{buildroot}%{_datadir}/systemd mkdir -p %{buildroot}%{_datadir}/pkgconfig mkdir -p %{buildroot}%{_localstatedir}/lib/systemd/catalog That's your call, but I think we'll be happier later. :) An alternate approach would be to make a source tarball containing all of these directories (along with the macro file), and just unpack it. 6. Can we get away with making this noarch?
Thanks very much for your input, Matt! I've updated spec and macro files to follow your suggestions. See http://vpavlin.fedorapeople.org/fakesystemd/ Regards, Vaclav
(In reply to Matthew Miller from comment #1) > > If possible, it shouldn't be shipped in primary repo and should be available only for building (Docker) images. > > That's not currently possible. Maybe in the future. We'll need to do some > sanity checking to make sure no installs pull this in instead of the real > systemd by accident. I'd like to know more about how exactly are we going to enforce that no one accidentally installs fakesystemd. I want to start working on minimal systemd to be used for multi app containers. Very similar to systemd-container we have in RHEL7. It will able to boot up little else than container, hence we don't want users to install it on real machine by mistake.
So, the theory is: put systemd in the @core group so that it's picked by default, not pulled in by deps. Once it's there, the Conflicts will keep anyone from adding fakesystemd by accident, and the protected packages feature of yum (and now DNF) will keep real systemd from being removed. That's the theory, at least. :)
FYI, systemd is in @core since F14 (see https://git.fedorahosted.org/cgit/comps.git/commit/?id=4e79f60c30b1cb6db55b11def06bd4b5e7e492f7)
Looks good. Conflicts with systemd on my laptop and does not install, so that's good. :) Review passed. Obviously contains directories owned by other packages, but that's kind of the point..
New Package SCM Request ======================= Package Name: fakesystemd Short Description: Docker-specific package to simulate systemd presence in system Upstream URL: None Owners: vpavlin Branches: f20 f21 InitialCC: vpavlin
WARNING: Upstream URL seems to be invalid
(In reply to Jon Ciesla from comment #9) > WARNING: Upstream URL seems to be invalid Yes, there is no upstream here (or, really, source); this is a stub package.
Then it would seem that the upstream is Fedora, you could use http://fedoraproject.org or something.
New Package SCM Request ======================= Package Name: fakesystemd Short Description: Docker-specific package to simulate systemd presence in system Upstream URL: http://fedoraproject.org Owners: vpavlin Branches: f20 f21 InitialCC: vpavlin
Git done (by process-git-requests).
What's the status? Shouldn't that package show up at one point?
No, please kill the package instead.
Sorry, I don't understand what you mean.
Afaik, this package was causing more problems then it was solving, and that's why it was never built and submitted as an update. If that is true, it would be best to clearly kill the package (make it a dead package).
Václav, can this bugzilla be closed and https://github.com/fedora-cloud/docker-brew-fedora/blob/master/fedora-docker-base.ks purged since I believe fakesystemd was made obsolete by systemd-container which was made obsolete by recent changes in systemd?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #17) > Afaik, this package was causing more problems then it was solving, and > that's why it was never built and submitted as an update. If that is true, > it would be best to clearly kill the package (make it a dead package). Could you specify? I believe this would still be useful as systemd and its dependencies still take up a lot of space (~16%) in a docker base image for seemingly no reason. As for how to handle the Conflicts, I think we can use coreutils-single as a model. Based on that, systemd should: Conflicts: fakesystemd Obsoletes: fakesystemd and then fakesystemd should: Provides: systemd If that is done, does that solve whatever problems there were?
(In reply to Yaakov Selkowitz from comment #19) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #17) > > Afaik, this package was causing more problems then it was solving, and > > that's why it was never built and submitted as an update. If that is true, > > it would be best to clearly kill the package (make it a dead package). > > Could you specify? I believe this would still be useful as systemd and its > dependencies still take up a lot of space (~16%) in a docker base image for > seemingly no reason. > > As for how to handle the Conflicts, I think we can use coreutils-single as a > model. Based on that, systemd should: > > Conflicts: fakesystemd > Obsoletes: fakesystemd > > and then fakesystemd should: > > Provides: systemd > > If that is done, does that solve whatever problems there were? I would rather go down the road and create an opt-in scheme, where packages remove the %systemd_requires macro, if the package is able to run without systemd. The systemd_{post,preun} macros don't fail, if anything goes wrong. E.g. packages, which rely on %sysusers_create would probably not work. Or if packages rely on a systemd API/ABI/functionality. Please let it be an opt-in, rather than a magic fakesystemd package, where support tickets will be opened, because the package doesn't work as advertised, because it really needs a functional systemd.
(In reply to Harald Hoyer from comment #20) > (In reply to Yaakov Selkowitz from comment #19) > > (In reply to Zbigniew Jędrzejewski-Szmek from comment #17) > > > Afaik, this package was causing more problems then it was solving, and > > > that's why it was never built and submitted as an update. If that is true, > > > it would be best to clearly kill the package (make it a dead package). > > > > Could you specify? I believe this would still be useful as systemd and its > > dependencies still take up a lot of space (~16%) in a docker base image for > > seemingly no reason. > > > > As for how to handle the Conflicts, I think we can use coreutils-single as a > > model. Based on that, systemd should: > > > > Conflicts: fakesystemd > > Obsoletes: fakesystemd > > > > and then fakesystemd should: > > > > Provides: systemd > > > > If that is done, does that solve whatever problems there were? > > I would rather go down the road and create an opt-in scheme, where packages > remove the > %systemd_requires > macro, if the package is able to run without systemd. Requires(post): systemd Requires(preun): systemd Requires(postun): systemd would become Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd > > The systemd_{post,preun} macros don't fail, if anything goes wrong. > > E.g. packages, which rely on %sysusers_create would probably not work. > > Or if packages rely on a systemd API/ABI/functionality. > > Please let it be an opt-in, rather than a magic fakesystemd package, where > support tickets will be opened, because the package doesn't work as > advertised, because it really needs a functional systemd.
(In reply to Harald Hoyer from comment #21) > (In reply to Harald Hoyer from comment #20) > > I would rather go down the road and create an opt-in scheme, where packages > > remove the > > %systemd_requires > > macro, if the package is able to run without systemd. > > Requires(post): systemd > Requires(preun): systemd > Requires(postun): systemd > > would become > > Recommends: systemd > OrderWithRequires(post): systemd > OrderWithRequires(preun): systemd > OrderWithRequires(postun): systemd That may very well be a better approach overall, but I'm not sure about the Recommends:, I think Suggests: or nothing at all would make more sense in at least some cases. What that does require is for systemd to handle all previously installed (but deferred) presets in %post [ $1 == 1 ]. How exactly?
> What that does require is for systemd to handle all previously installed (but > deferred) presets in %post [ $1 == 1 ]. How exactly? We could add 'if[ $1 == 1 ]; then systemctl preset-all; fi', which would call presets for all packages that were installed previously. Unfortunately it would also undo any enablement/disablement that was done previously. We don't keep any state that would tell us for which packages systemd preset should be called, instead every package does the call itself on initial install. But it'd be really unexpected to have a normal system without systemd installed in the initial transaction, so maybe that's OK. We'd have to document the fact that initial installation of systemd removes unit enablement configuration. We already call 'udevadm hwdb --update' and 'journalctl --update-catalog' and 'systemd-tmpfiles --create' in systemd %post, so other calls to systemd functionality that happen in package scriptlets should be covered. (In reply to Yaakov Selkowitz from comment #22) > > Recommends: systemd > > OrderWithRequires(post): systemd > > OrderWithRequires(preun): systemd > > OrderWithRequires(postun): systemd I'd rather turn this into another macro (%systemd_ordering ?). > That may very well be a better approach overall, but I'm not sure about the > Recommends:, I think Suggests: or nothing at all would make more sense in at > least some cases. Either would work. Recommends is likely to be ignored when creating a minimal image anyway. But Recommends has the advantage that systemd would be pulled in when creating a chroot with dnf. PS. I'll remove needinfo, because Vaclav retired the package in pkgdb last year. Let's keep the bug open for discussion.
I would not support to install systemd in post. Either it's there from the beginning or not.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #23) > > > Recommends: systemd > > > OrderWithRequires(post): systemd > > > OrderWithRequires(preun): systemd > > > OrderWithRequires(postun): systemd > I'd rather turn this into another macro (%systemd_ordering ?). %systemd_recommends could hold all of the above. Another approach would be: Requires: systemd %systemd_ordering and Recommends: systemd %systemd_ordering because the ordering works in both scenarios.
I think the macro should contain the whole thing, to make it as simple to use as possible. But that's a detail that can be worked out later. The changes required are trivial to implement, just a few lines in systemd.macros. We can just add it and allow people to use it, but the FPC should probably update the guidelines to mention the new macro.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #26) > I think the macro should contain the whole thing, to make it as simple to > use as possible. But that's a detail that can be worked out later. I'm still not convinced of the need for even Recommends: systemd here. Compare the desktop-database, mimeinfo, and icon-cache scriptlets, which explicitly do NOT mandate any Requires:. I believe this is the same: if systemd is already present, then the scriptlets will succeed, otherwise they are ignored. Only packages which are completely useless outside of systemd should then use %systemd_requires. > The changes required are trivial to implement, just a few lines in > systemd.macros. We can just add it and allow people to use it, but the FPC > should probably update the guidelines to mention the new macro. Yes, this should go through FPC once we have some agreement on the above.
What more is needed to move this forward?
Harald, can we get this going?
Is the a plan in place to change the Fedora base image to drop systemd and carry fakesystemd? If there is one, could some links to where this change is being proposed and discussed be added here? If there is not and base images will always carry systemd, I wonder what the purpose and expected use of fakesystemd would be. The images would already have systemd in them, and even if layered images replaced it with fakesystemd, users would still have to get the base image which had it, killing the whole purpose.
(In reply to Jan Pazdziora from comment #30) > Is the a plan in place to change the Fedora base image to drop systemd and > carry fakesystemd? No, the plan currently being discussed is for the Docker base image to simply drop systemd by making sure nothing pulls it in as a dependency unless it *really* needs it.
(In reply to Yaakov Selkowitz from comment #31) > > No, the plan currently being discussed is for the Docker base image to > simply drop systemd by making sure nothing pulls it in as a dependency > unless it *really* needs it. Could you please add link to where this discussion is taking place?
(In reply to Jan Pazdziora from comment #30) > Is the a plan in place to change the Fedora base image to drop systemd and > carry fakesystemd? No; see above starting at comment 20 for the current plan.
Updating needinfo with Harald's correct email address.
https://github.com/systemd/systemd/pull/3776
Maybe we can add a check in the %pre macro of systemd, which recognizes already populated /lib/systemd/system or /usr/lib/tmpfiles.d and prints out a big fat warning on first installation. So, here is my recommendation for the package guidelines: If a package is suitable for an alternative init system or e.g. container image, and does not require any of the systemd mechanisms e.g. to install UID, GID, or tmpfiles, it can choose to use the %systemd_ordering macro instead of the %systemd_requires macro. Adding "Recommends: systemd" or "Suggests: systemd" is optional. Note: installing systemd afterwards in a separate rpm transaction does not produce the same result.
Policy guideline discussion: https://fedorahosted.org/fpc/ticket/644
(In reply to Harald Hoyer from comment #36) > Note: installing systemd afterwards in a separate rpm transaction does not > produce the same result. What about the proposal in comment 23 wrt handling pre-installed presets in %post if [ $1 == 1 ]?
OK, let's see how that works out in real life. Implemented in http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?id=46083abe1a4de3328d84e4a32ee22c78ac414b03, but I didn't rebuild.
Sorry, but it...doesn't work well. At all. preset-all doesn't really work right. https://bugzilla.redhat.com/show_bug.cgi?id=1363858 I am going to revert the change in the systemd package for now since it broke tty1 and thus broke all openQA tests.
I've just reapplied the change from #c23 in Rawhide, because it should help with https://bugzilla.redhat.com/show_bug.cgi?id=1647172 . So we can close this as FIXED again, I guess! Even though I don't really remember what the change was even supposed to help with... preset-all got fixed up upstream, so the problems from 1363858 should not happen again.