Hide Forgot
Description of problem: Before the package split of systemd you could install the latest builds on older Fedora releases ( like systemd-229 F24 builds on F23 hosts ) after the package split it fails which indicates upgrades from releases prior to F24 will fail as well. Version-Release number of selected component (if applicable): Installed version systemd-229-2.fc24.x86_64 systemd-libs-229-2.fc24.x86_64 systemd-compat-libs-229-2.fc24.x86_64 Updating to systemd-229-7.fc24.x86_64.rpm systemd-compat-libs-229-7.fc24.x86_64.rpm systemd-container-229-7.fc24.x86_64.rpm systemd-libs-229-7.fc24.x86_64.rpm systemd-udev-229-7.fc24.x86_64.rpm How reproducible: Always Steps to Reproduce: 1. update/install systemd release older than the package split 2. upgrade to a release after the package split 3. Actual results: dnf upgrade systemd-* Last metadata expiration check: 0:02:30 ago on Tue Apr 26 06:08:54 2016. Package systemd-container not installed, cannot update it. Package systemd-udev not installed, cannot update it. Error: nothing provides libmicrohttpd.so.12()(64bit) needed by systemd-container-229-7.fc24.x86_64 dnf install systemd-container-229-7.fc24.x86_64.rpm systemd-udev-229-7.fc24.x86_64.rpm Last metadata expiration check: 0:16:24 ago on Tue Apr 26 06:08:54 2016. Error: nothing provides systemd(x86-64) = 229-7.fc24 needed by systemd-udev-229-7.fc24.x86_64. nothing provides libmicrohttpd.so.12()(64bit) needed by systemd-container-229-7.fc24.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages) rpm -Uhv systemd-* error: Failed dependencies: libmicrohttpd.so.12()(64bit) is needed by systemd-container-229-7.fc24.x86_64 Most likely there will be spectacular upgrade fails on udev as well for those that have upgraded for several fedora releases since their instalments that contain installed components that depend on udev and or systemd but lack the "new" dependency on systemd-udev Expected results: There should not be any dependency in libmicrohttpd ( provided by systemd-journal-remote which was not previously installed ) in the systemd-container package and update/upgrade should proceed without any failure. Additional info: Was the upgrade and update path not thoroughly tested when this was split ( from at least full blown F21 instalment that was upgrade to F24 ) and components that had prior dependency on udev/systemd fixed to have correct dependency on the new splitted component if applicable?
The dependency on libmicrohttpd is a bug. It seems that /usr/lib/systemd/systemd-journal-remote is owned by both systemd-container and systemd-journal-remote. This of course needs to be fixed. But not being to upgrade if you're missing dependencies is not a bug. If you want to upgrade on the command line, you have to provide all the packages, including any new deps.
Fixed in rawhide, but I'll leave this as POST to remember to fix in in F24 after the freeze period is over.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > The dependency on libmicrohttpd is a bug. It seems that > /usr/lib/systemd/systemd-journal-remote is owned by both systemd-container > and systemd-journal-remote. This of course needs to be fixed. > > But not being to upgrade if you're missing dependencies is not a bug. If you > want to upgrade on the command line, you have to provide all the packages, > including any new deps. There should not be any dependency on systemd-journal-remote since it was standalone before and there needs to be correct dependency between the splitted components among themselves as well. Also any component that required systemd ( or udev ) that now might require sub-component instead ( like systemd-udev ) instead should be fixed so you need to go through all the dependency on systemd in all components, view why systemd is required there and add the correct dependency on relevant sub-component if applicable. Is the plan to split out Pam in F24 since I see that has been done in F25 builds ( systemd-pam and perhaps the plan is to split systemd-timers and systemd-networkd out as well? ) or is that going to be F25 only change?
The split has nothing inherent to do with the added dependency on libµhttpd, I just made a copy&paste mistake in %files section. > Also any component that required systemd ( or udev ) that now might require > sub-component instead ( like systemd-udev ) instead should be fixed so you > need to go through all the dependency on systemd in all components, view why > systemd is required there and add the correct dependency on relevant > sub-component if applicable. It's not so bad. Whether udev is necessary is a property of the system, and individual packages don't have much to say here. This situation is similar to the kernel: you cannot make a package dependency on the kernel, you just assume that it'll be there if it's needed. OTOH, if there is a subpackage which uses some component of udev (for example calls /usr/bin/udevadm and will crash if it's not there), then it should have a dependency. If you know of any such cases, please file a bug or just let me know. > Is the plan to split out Pam in F24 since I see that has been done in F25 > builds ( systemd-pam and perhaps the plan is to split systemd-timers and > systemd-networkd out as well? ) or is that going to be F25 only change? Yes, the plan is to do all the chagnes currently in rawhide in F24 too, after the beta freeze is over. systemd-pam is required by the main package, so this change has very little impact is main systemd package is installed.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > > It's not so bad. Whether udev is necessary is a property of the system, and > individual packages don't have much to say here. This situation is similar > to the kernel: you cannot make a package dependency on the kernel, you just > assume that it'll be there if it's needed. That assumptions is what leads to the messy situation that the core/baseOS is currently in since package maintainers routinely assumed this and that which at one point made up the core/baseOS would be there indefinitely. That leads to a scenario when you are trying to work on a feature in the distribution or otherwise simply trying to determine how an scope of a project or task will affect the distribution, cannot be reliably determine by whomever is overseeing or otherwise performing the task. So the lazyness and incorrect assumption of single maintainers which leads him to not declaring proper dependency in package(s) leads to incorrect assumption by the feature owner/project leader/task manager which then leads to incorrect scope determine by the task at hand, which leads to incorrect conclusion of fesco which then leads to broken or half finished implementation of said feature or task which eventually is breaking working system for end users. You cant fix stupid but you can prevent it from spreading so you really cant blame that ignant package maintainer but the process that should be catching/enforcing correct dependency in packages which highlights one of biggest fundamental failure of FESCo and FPC and it's sole purpose in the distribution.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.