Hide Forgot
Description of problem: Upgrading rsyslog to version 5.8.7-1.fc16.x86_64 fails due to dependency problems. Version-Release number of selected component (if applicable): 5.8.7-1.fc16.x86_64 How reproducible: always at the moment Steps to Reproduce: 1.yum upgrade rsyslog Downloading Packages: Running Transaction Check ERROR with transaction check vs depsolve: systemd-sysv is needed by rsyslog-5.8.7-1.fc16.x86_64 Please report this error in http://yum.baseurl.org/report ** Found 25 pre-existing rpmdb problem(s), 'yum check' output follows: (all systemd-sysv related)
ping!
Works for me. Do you have systemd-sysv installed? Do you have yum repositories set up correctly? You might try to clean up yum cache and attempt to update again.
My repositories are set up correctly, however systemd-sysv was not installed. How come that this is not installed while so many packages require it. Should dependencies not resolve this?
I'm not really sure why it failed. From which version of rsyslog did you upgrade? Is this a clean install of f16 or an upgrade from a previous version? The f16 package should have the correct dependencies. The f15 package seems to miss the systemd-sysv dep, but the issue doesn't seem to be rsyslog specific as per the report. Reassigning to systemd.
It was a clean install of f16.
It's a dependency for the %post scriptlet. rsyslog.spec says: Requires(post): systemd-sysv I don't see systemd doing anything wrong. Moving to yum.
> ** Found 25 pre-existing rpmdb problem(s), 'yum check' output follows: > (all systemd-sysv related) ...this means that the problems are already in the rpmdb, and need to be fixed before yum can behave "well" (yum assumes that if rsyslog needs XYZ and rsyslog is installed, and XYZ is installed). Just install everything it needs, or remove it and then install it again.
(In reply to comment #7) > ...this means that the problems are already in the rpmdb, and need to be fixed > before yum can behave "well" (yum assumes that if rsyslog needs XYZ and rsyslog > is installed, and XYZ is installed). One problem is that yum happily moves the rpmdb into that broken state. Initial state: Both rsyslog and systemd-sysv are installed, "yum check" is clean. # yum remove systemd-sysv [... completes successfully without complaints ...] # yum check ... rsyslog-5.8.5-1.fc16.x86_64 has missing requires of systemd-sysv ... Error: check all
If it's Requires(post), you can remove it once it's installed. I suppose it should be pulled back in on upgrade?
The problem is that above the rpm layer, we don't know anything about the different types of requires. I guess it's possible that looking at specific bits in the rpm header would let us know what is happening for local rpm files or the rpmdb, but we'd still have problems like: % rpm -q --requires rsyslog | fgrep systemd-sysv systemd-sysv % rpm -q --whatrequires systemd-sysv no package requires systemd-sysv ...and basically the same thing happens on remove, we ask rpm "does anything require systemd-sysv" ... rpm says no, so we remove it. Then "yum check" will walk the requires list of all the packages, and give failures ... and "yum upgrade" will see (can only see) that foo requires bar, which hasn't changed ... not changed == bar must be installed == no need to do anything. Also while people might be happy with "yum upgrade rsyslog" re-installing systemd-sysv, they are going to be much less happy if "yum remove rsyslog" requires that. I thought this had been "fixed" on the rpm side by treating removal of Requires(post) as not acceptable? To fix it properly on the yum side would require a lot of work, and new repodata (and allowing removes to install things). Reassigning to rpm guys.
Maybe it was only Requires(postun), and not Requires(post), which were treated as the same as requires? That solves the biggest problem of install needed for remove, but we still can't easily do install needed for upgrade.
(In reply to comment #10) > The problem is that above the rpm layer, we don't know anything about the > different types of requires. > I guess it's possible that looking at specific bits in the rpm header would > let us know what is happening for local rpm files or the rpmdb, but we'd still > have problems like: > > % rpm -q --requires rsyslog | fgrep systemd-sysv > systemd-sysv > % rpm -q --whatrequires systemd-sysv > no package requires systemd-sysv Try 'rpm -qv --requires rsyslog' for more informative output, it'll tell you this is a %post dependency. That information is available to python just as much as any other dependency data (and yes I know yum has never cared about any of it), RPMSENSE_SCRIPT_POST etc. > ...and basically the same thing happens on remove, we ask rpm "does anything > require systemd-sysv" ... rpm says no, so we remove it. Which is perfectly fine: Requires(post) dependency says that the dependency is only needed for execution of %post scriptlet, and nothing else. Once the package has been installed, %post will never be executed again for that specific package instance so ok to remove it. Of course on upgrade, the %post of the updating package will be run, but that's a different package that might (or might not) have completely different dependencies on its %post. > Then "yum check" will walk the requires list of all the packages, and give > failures ... and "yum upgrade" will see (can only see) that foo requires bar, > which hasn't changed ... not changed == bar must be installed == no need to do > anything. Well, that's not a valid assumption really. If something is required then actually check whether its installed or not, instead of tracking "did it change?" status. Besides fixing this case (without even having to look at the dependency type bits), it'd make yum behave smarter in face of 'rpm -e --nodeps foo' situations. > Also while people might be happy with "yum upgrade rsyslog" re-installing > systemd-sysv, they are going to be much less happy if "yum remove rsyslog" > requires that. > I thought this had been "fixed" on the rpm side by treating removal of > Requires(post) as not acceptable? > To fix it properly on the yum side would require a lot of work, and new > repodata (and allowing removes to install things). Reassigning to rpm guys. Rpm has never allowed removing Requires(postun) (or preun) dependencies as those scriptlets haven't been executed at the time of package installation. It'd indeed seem bizarre and annoying if removal would require installing additional dependencies. And FWIW, this is the way rpm has behaved for the last 11+ years, the only fixes in this area have been correctly handling combined Requires(post,postun) style dependencies.
I think I've fixed this, we now use the rpmsense bits in the requires flags to create a list of "strong requires" (anything that doesn't have SENSE_PRE or SENSE_POST) ... and use that for the depsolver. It seems to work here, asking for comments upstream. Note that "yum reinstall rsyslog" will reinstall systemd-sysv.
*** Bug 795907 has been marked as a duplicate of this bug. ***
yum-3.4.3-22.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/yum-3.4.3-22.fc16
Package yum-3.4.3-22.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing yum-3.4.3-22.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3766/yum-3.4.3-22.fc16 then log in and leave karma (feedback).
#795907 still exists for me with yum-3.4.3-22.fc16.noarch
Package yum-3.4.3-23.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing yum-3.4.3-23.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3766/yum-3.4.3-23.fc16 then log in and leave karma (feedback).
yum-3.4.3-23.fc16 fixes #795907 for me
yum-3.4.3-23.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 552818 has been marked as a duplicate of this bug. ***