Description of problem: Lately I noticed that systemd is pulled in the minimal buildroot which wasn't the case before. This increases buildroot quite a bit. Version-Release number of selected component (if applicable): elfutils-0.173-1.fc29 How reproducible: Always. Steps to Reproduce: 1. Install elfutils-libs Actual results: It pulls elfutils-default-yama-scope which pulls systemd. Expected results: It doesn't pull systemd. Additional info: What do you think about changing Requires to Recommends? Or even Suggests for this package. Is it really required in runtime? I'm pretty sure it isn't for the buildroot. So choose Recommends if it improves UX a lot and Suggests if it is just nice-to-have.
(In reply to Igor Gnatenko from comment #0) > Description of problem: > Lately I noticed that systemd is pulled in the minimal buildroot which > wasn't the case before. This increases buildroot quite a bit. > [...] > Expected results: > It doesn't pull systemd. I would actually expect an init system to be available. But I can see that if that isn't necessary then pulling in all of systemd might be too much. > Additional info: > What do you think about changing Requires to Recommends? Or even Suggests > for this package. Is it really required in runtime? I'm pretty sure it isn't > for the buildroot. I think that is the wrong point to try to break the dependency chain. Lets look at what the direct reason is for pulling in systemd. We have the following for the default-yama-scope package: # For the sysctl_apply macro %{?systemd_requires} BuildRequires: systemd >= 215 The build requires is for getting the sysctl_apply macro itself. And shouldn't really be a problem, since it is only required during build. So the issue is %{?systemd_requires} which comes from macros.systemd: %systemd_requires \ Requires(post): systemd \ Requires(preun): systemd \ Requires(postun): systemd \ %{nil} And the sysctl_apply macro: %sysctl_apply() \ /usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || : \ %{nil} Which is required to "activate" the sysctl installed without needing a reboot. But we also have: %post default-yama-scope # Due to circular dependencies might not be installed yet, so double check. # (systemd -> elfutils-libs -> default-yama-scope -> systemd) if [ -x /usr/lib/systemd/systemd-sysctl ] ; then %sysctl_apply 10-default-yama-scope.conf fi So, we already cope with it not being available. Which suggests (haha, pun intended) that this would be a better point to try to break the hard requirement.
(In reply to Mark Wielaard from comment #1) > (In reply to Igor Gnatenko from comment #0) > > Description of problem: > > Lately I noticed that systemd is pulled in the minimal buildroot which > > wasn't the case before. This increases buildroot quite a bit. > > [...] > > Expected results: > > It doesn't pull systemd. > > I would actually expect an init system to be available. But I can see that > if that isn't necessary then pulling in all of systemd might be too much. Why would minimal buildroot need systemd? it needs just rpm-build + coreutils. We are in process to remove gcc from there. > > Additional info: > > What do you think about changing Requires to Recommends? Or even Suggests > > for this package. Is it really required in runtime? I'm pretty sure it isn't > > for the buildroot. > > I think that is the wrong point to try to break the dependency chain. > Lets look at what the direct reason is for pulling in systemd. > > We have the following for the default-yama-scope package: > > # For the sysctl_apply macro > %{?systemd_requires} > BuildRequires: systemd >= 215 > > The build requires is for getting the sysctl_apply macro itself. > And shouldn't really be a problem, since it is only required during build. > > So the issue is %{?systemd_requires} which comes from macros.systemd: > > %systemd_requires \ > Requires(post): systemd \ > Requires(preun): systemd \ > Requires(postun): systemd \ > %{nil} > > And the sysctl_apply macro: > > %sysctl_apply() \ > /usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || : \ > %{nil} > > Which is required to "activate" the sysctl installed without needing a > reboot. > > But we also have: > > %post default-yama-scope > # Due to circular dependencies might not be installed yet, so double check. > # (systemd -> elfutils-libs -> default-yama-scope -> systemd) > if [ -x /usr/lib/systemd/systemd-sysctl ] ; then > %sysctl_apply 10-default-yama-scope.conf > fi > > So, we already cope with it not being available. Which suggests (haha, pun > intended) that this would be a better point to try to break the hard > requirement. No, I meant to change "Requires: default-yama-scope" to "Recommends: default-yama-scope".
If you change Requires to Recommends, you already break dependency loop ;)
Indeed there is another way to break cycle: remove %systemd_requires. But the question is why does this package has to be set as Requires and not Recommends? All of the installations install Recommends by default?.
(In reply to Igor Gnatenko from comment #2) > (In reply to Mark Wielaard from comment #1) > > So, we already cope with it not being available. Which suggests (haha, pun > > intended) that this would be a better point to try to break the hard > > requirement. > > No, I meant to change "Requires: default-yama-scope" to "Recommends: > default-yama-scope". That is the wrong point to break the dependency loop. Lets fix the direct dependency instead of trying to hack around it through indirect dependencies. If we don't fix the root cause we will get the issue back later if some other indirect dependency shows up.
(In reply to Mark Wielaard from comment #5) > (In reply to Igor Gnatenko from comment #2) > > (In reply to Mark Wielaard from comment #1) > > > So, we already cope with it not being available. Which suggests (haha, pun > > > intended) that this would be a better point to try to break the hard > > > requirement. > > > > No, I meant to change "Requires: default-yama-scope" to "Recommends: > > default-yama-scope". > > That is the wrong point to break the dependency loop. Lets fix the direct > dependency instead of trying to hack around it through indirect > dependencies. If we don't fix the root cause we will get the issue back > later if some other indirect dependency shows up. I see 2 options here: * Change Requires to Recommends, this seems more logical to me (and as a benefit we get rid out of systemd from buildroot) * Remove %systemd_requires usage and hope that systemd is there (fixes particular problem, but doesn't sound right)
(In reply to Igor Gnatenko from comment #6) > I see 2 options here: > * Change Requires to Recommends, this seems more logical to me (and as a > benefit we get rid out of systemd from buildroot) > * Remove %systemd_requires usage and hope that systemd is there (fixes > particular problem, but doesn't sound right) I went for the Recommends option. I added some comments to the spec file to explain why I believe it will work out even though we really need systemd-sysctl in post.
Coolio, we are out of systemd in buildroot!