Hide Forgot
Description of problem: The certmonger package has Requires(post): systemd-sysv even if it probably is not needed. Version-Release number of selected component (if applicable): certmonger-0.70-2.el7.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Have RHEL 7 installation without systemd, for example in a Docker container with fakesystemd. 2. Run yum install -y certmonger. Actual results: Transaction check error: file /usr/lib/rpm/macros.d/macros.systemd from install of systemd-208-11.el7.x86_64 conflicts with file from package fakesystemd-1-14.el7.x86_64 Expected results: The installation passes, certmonger does not force the systemd-sys (and thus systemd) installation. Additional info: Of course, it is possible to do yum swap -y -- remove fakesystemd -- install systemd systemd-libs but it increases the image size unnecessarily.
Ran into a similar problem but with tomcat in place of certmonger. Filed BZ 1122252 for it.
The systemd-sysv package used to contain the systemd-sysv-convert tool, but it was phased out in Fedora 20 and I based on that I assume it will be after 7.x as well. If your package's scriptlets don't call the tool, or will be modified to not call it (IIRC, current packaging guidelines no longer require you to use it) you won't need it.
I think the simplest solution is to let fakesystemd also provide "systemd-sysv" as proposed in BZ #1126409. systemd-sysv-convert will obviously fail but that shouldn't affect the result of the package installation. Feel free to prove me wrong, Vaclav *** This bug has been marked as a duplicate of bug 1126409 ***
Reopening. I don't think it's correct to use bug 1126409 as the sole vehicle to address the issue. Yes, fakesystemd can provide systemd-sysv but if there's generic problem of packages like certmonger requiring something it does not need to, we should fix those packages as well -- the dependency cruft has the potential to bite us not just in the specific case of fakesystemd. Running rpm -qp --scripts certmonger-0.70-2.el7.i686.rpm | grep systemd-sysv-convert does not find anything so I assume (correct me if I'm wrong) that certmonger's Requires can be safely changed.
It was called in a trigger, so that query won't show it -- try --triggers instead of --scripts. I think the proper thing is to just use the fact that we know a given release will no longer includes systemd-sysv-convert, and update the packaging to not bother trying to call it when we know we're being built for such a release.
(In reply to Nalin Dahyabhai from comment #9) > It was called in a trigger, so that query won't show it -- try --triggers > instead of --scripts. You are right, it's in --triggers: $ rpm -qp --triggers certmonger-0.70-2.el7.i686.rpm | grep systemd-sysv-convert # "systemd-sysv-convert --apply certmonger". /usr/bin/systemd-sysv-convert --save certmonger >/dev/null 2>&1 ||: > I think the proper thing is to just use the fact that we know a given > release will no longer includes systemd-sysv-convert, and update the > packaging to not bother trying to call it when we know we're being built for > such a release. I concur.
Unfortunately, in my latest 7.x tree, systemd-sysv-convert is still present, which means it's not as clear cut as I'd like Our choices appear to be to either defer this to the next major release, or to stop trying to support the upgrade scenario that systemd-sysv-convert is meant to help us with in this release, even though it's there. I lean slightly toward the first option, but I could be talked out of it. Is this going to break things horribly if left as-is, or is this a would-be-nice item that can be left for later?
Okay, conditional logic which uses systemd-sysv-convert is conditionalized to Fedora releases 16 through 19, inclusive, and not for any RHEL release.
How to verify this? Checking only that dependency on systemd-sysv removed from certmonger deplist?
(In reply to Kaleem from comment #16) > How to verify this? > > Checking only that dependency on systemd-sysv removed from certmonger > deplist? That, and verifying that none of the package's scripts or triggers attempt to use facilities that only are provided by systemd-sysv, so that the dependency isn't merely hidden, but is actually gone.
Verified certmonger version: ------------------ [root@dhcp207-1 ~]# rpm -q certmonger certmonger-0.75.14-2.el7.x86_64 [root@dhcp207-1 ~]# snip from automation log: ========================= :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: certmonger_1104138 - certmonger requires systemd-sysv when it wouldn't need to :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ BEGIN ] :: restarting ipa service :: actually running 'service ipa restart' Redirecting to /bin/systemctl restart ipa.service :: [ PASS ] :: restarting ipa service (Expected 0, got 0) :: [ BEGIN ] :: certmonger's triggers does not uses systemd-sysv-convert :: actually running 'rpm -q --triggers certmonger | grep systemd-sysv-convert' :: [ PASS ] :: certmonger's triggers does not uses systemd-sysv-convert (Expected 1, got 1) :: [ BEGIN ] :: certmonger's scripts does not uses systemd-sysv-convert :: actually running 'rpm -q --scripts certmonger | grep systemd-sysv-convert' :: [ PASS ] :: certmonger's scripts does not uses systemd-sysv-convert (Expected 1, got 1)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0437.html