Bug 1118740 - Remove the hard dependency on systemd for packages, which make use of systemd rpm macros
Summary: Remove the hard dependency on systemd for packages, which make use of systemd...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: base-minimization
TreeView+ depends on / blocked
 
Reported: 2014-07-11 12:38 UTC by Václav Pavlín
Modified: 2018-11-09 00:43 UTC (History)
13 users (show)

Fixed In Version: systemd-231-2.fc25.x86_64
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-09 00:43:17 UTC
Type: ---
Embargoed:
mattdm: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1363858 0 unspecified CLOSED No tty on vt1 since change to systemd scriptlets to run 'systemctl preset-all' instead of specific preset commands 2021-02-22 00:41:40 UTC

Internal Links: 1363858

Description Václav Pavlín 2014-07-11 12:38:41 UTC
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

Comment 1 Matthew Miller 2014-07-11 15:46:19 UTC
> 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.

Comment 2 Matthew Miller 2014-07-14 20:11:45 UTC
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?

Comment 3 Václav Pavlín 2014-07-22 16:21:22 UTC
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

Comment 4 Michal Sekletar 2014-07-25 09:21:02 UTC
(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.

Comment 5 Matthew Miller 2014-07-25 12:54:40 UTC
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. :)

Comment 6 Václav Pavlín 2014-07-28 10:53:49 UTC
FYI, systemd is in @core since F14 (see https://git.fedorahosted.org/cgit/comps.git/commit/?id=4e79f60c30b1cb6db55b11def06bd4b5e7e492f7)

Comment 7 Matthew Miller 2014-08-04 13:29:49 UTC
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..

Comment 8 Václav Pavlín 2014-08-11 13:36:33 UTC
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

Comment 9 Gwyn Ciesla 2014-08-11 15:42:12 UTC
WARNING: Upstream URL seems to be invalid

Comment 10 Matthew Miller 2014-08-11 15:52:35 UTC
(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.

Comment 11 Gwyn Ciesla 2014-08-13 10:19:27 UTC
Then it would seem that the upstream is Fedora, you could use
http://fedoraproject.org or something.

Comment 12 Václav Pavlín 2014-08-15 09:22:46 UTC
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

Comment 13 Gwyn Ciesla 2014-08-15 11:50:06 UTC
Git done (by process-git-requests).

Comment 14 Tobias Florek 2015-06-09 10:05:22 UTC
What's the status? Shouldn't that package show up at one point?

Comment 15 Zbigniew Jędrzejewski-Szmek 2015-06-09 12:21:21 UTC
No, please kill the package instead.

Comment 16 Tobias Florek 2015-06-09 12:30:29 UTC
Sorry, I don't understand what you mean.

Comment 17 Zbigniew Jędrzejewski-Szmek 2015-06-09 12:50:29 UTC
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).

Comment 18 Jan Pazdziora 2015-10-26 15:27:56 UTC
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?

Comment 19 Yaakov Selkowitz 2016-04-12 14:35:25 UTC
(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?

Comment 20 Harald Hoyer 2016-04-14 14:22:12 UTC
(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.

Comment 21 Harald Hoyer 2016-04-14 14:28:11 UTC
(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.

Comment 22 Yaakov Selkowitz 2016-04-14 14:45:11 UTC
(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?

Comment 23 Zbigniew Jędrzejewski-Szmek 2016-04-14 15:42:53 UTC
> 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.

Comment 24 Harald Hoyer 2016-04-14 15:47:46 UTC
I would not support to install systemd in post. Either it's there from the beginning or not.

Comment 25 Harald Hoyer 2016-04-14 15:52:57 UTC
(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.

Comment 26 Zbigniew Jędrzejewski-Szmek 2016-04-14 16:03:18 UTC
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.

Comment 27 Yaakov Selkowitz 2016-05-30 17:28:44 UTC
(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.

Comment 28 Yaakov Selkowitz 2016-06-20 04:40:02 UTC
What more is needed to move this forward?

Comment 29 Yaakov Selkowitz 2016-06-28 18:16:27 UTC
Harald, can we get this going?

Comment 30 Jan Pazdziora 2016-06-29 06:28:05 UTC
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.

Comment 31 Yaakov Selkowitz 2016-06-29 07:29:18 UTC
(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.

Comment 32 Jan Pazdziora 2016-06-29 08:01:51 UTC
(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?

Comment 33 Yaakov Selkowitz 2016-07-21 19:37:36 UTC
(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.

Comment 34 Brendan Conoboy 2016-07-21 19:39:21 UTC
Updating needinfo with Harald's correct email address.

Comment 35 Harald Hoyer 2016-07-22 06:56:00 UTC
https://github.com/systemd/systemd/pull/3776

Comment 36 Harald Hoyer 2016-07-22 07:09:48 UTC
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.

Comment 37 Yaakov Selkowitz 2016-07-26 21:00:34 UTC
Policy guideline discussion: https://fedorahosted.org/fpc/ticket/644

Comment 38 Yaakov Selkowitz 2016-07-26 21:03:36 UTC
(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 ]?

Comment 39 Zbigniew Jędrzejewski-Szmek 2016-07-27 00:16:25 UTC
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.

Comment 40 Adam Williamson 2016-08-03 18:31:17 UTC
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.

Comment 41 Adam Williamson 2018-11-09 00:43:17 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.