Bugzilla – Bug 1187332
zypper ignores the ordering constraints specified by OrderWithRequires
Last modified: 2023-04-06 10:06:09 UTC
As part of fixing https://bugzilla.opensuse.org/show_bug.cgi?id=1186561 I tried using %systemd_ordering so systemd is installed before pipewire on a brand new installation. After the installation is done executing the following command gave: > grep -e "install|pipewire|0.3.27" -e "install|systemd|246" /var/log/zypp/history 2021-05-24 09:42:57|install|pipewire|0.3.27-2.1|x86_64||openSUSE-20210522-0|b811f374ec767b8f176864ae37e24be5218e6230741e3707bda934c01486e6c1| 2021-05-24 09:43:42|install|systemd|246.13-1.2|x86_64||openSUSE-20210522-0|06a9eb6641d7a28d2a1d2b100828800db9d11bc1bf196c5a04cca1ced1680339| So it seems %systemd_ordering is being ignored by zypper.
I'm not 100% sure but this is probably a result of how we execute the transaction currently. Adding Michael to clarify.
So the %systemd_ordering macro is using OrderWithRequires, which is not part of the repomd metadata. So its not possible for the solver to use it for ordering. So currently the macro should have "Suggests: systemd" to make sure the ordering works correctly.
(In reply to Benjamin Zeller from comment #2) > So the %systemd_ordering macro is using OrderWithRequires, which is not part > of the repomd metadata. So its not possible for the solver to use it for > ordering. Is there any plan to address this so OrderWithRequires: works as expected also on openSUSE ? > So currently the macro should have "Suggests: systemd" to make sure the > ordering works correctly. But is this really equivalent (otherwise what would have been the point to introduce OrderWithRequires in the first place) ? IMU "OrderWithRequires:" would make the transaction fail if systemd is part of it and cannot be installed due to unsolvable dependencies unlike "Suggests:". Maybe something like the following would be more appropriated ? Requires: (systemd if systemd)
"Requires: (systemd if systemd)" is a no-op. The OrderWithRequires hint is only used in rpm's transaction ordering code, it will never fail a transaction. Rpm upstream added "OrderWithRequires" because "Suggests" is outside the scope of rpm (handled in the solver engines), so they added something new to be sure that nothing breaks. See https://github.com/rpm-software-management/rpm/commit/5c43095e1d78b3befe93c746fd182746c3b96c92 (Suggests also helps the solver to choose a candidate if there are multiple providers of a dependency.)
Spoke too soon about that "(systemd if systemd)". I think that it would actually work. The solver ignores it completely (that's why I said it's a no-op), but the ordering code just looks at the first part of the if. (But it's still pretty gross...)
(In reply to Franck Bui from comment #3) > (In reply to Benjamin Zeller from comment #2) > > So the %systemd_ordering macro is using OrderWithRequires, which is not part > > of the repomd metadata. So its not possible for the solver to use it for > > ordering. > > Is there any plan to address this so OrderWithRequires: works as expected > also on openSUSE ? We are currently experimenting with a more upstream compatible way to execute rpm transactions, its possible that this work will also enable OrderWithRequires, but that's something I can't promise at this point.
(In reply to Michael Schröder from comment #4) > Rpm upstream added "OrderWithRequires" because "Suggests" is outside the > scope of rpm (handled in the solver engines), so they added something new to > be sure that nothing breaks. Thanks but I'm still not sure to understand what the problem is actually... Assuming that the version of rpm shipped by TW understands "OrderWithRequires:", if "pipewire" and "systemd" both need to be updated, why would "rpm -U systemd pipewire" would update pipewire first as it's described in comment #0 ? Isn't it a bug in rpm ?
(In reply to Benjamin Zeller from comment #6) > We are currently experimenting with a more upstream compatible way to > execute rpm > transactions, its possible that this work will also enable > OrderWithRequires, but that's something I can't promise at this point. Do you have any pointer that would explain the problems this work is addressing ? Maybe that would help understanding the actual issue.
libzypp has an "DownloadAsNeeded" mode where it calls rpm to install each package individually. In that case, the ordering is not done by rpm but by libzypp. The problem here is that the OrderWithRequires is simply not present in the repo metadata, so libzypp cannot access it. Since some years the default has switched to "DownloadInAdvance", which makes zypp download all rpms first and then to the transaction. In that case it could retrieve the OrderWithRequires deps from the downloaded rpms, but there's currently no code that does this. It also still uses individual rpm calls. The zypp folks currently experiment with using a single transaction call for installation, which would solve this as rpm would do the ordering. But this is still work in progress.
(In reply to Michael Schröder from comment #9) > The zypp folks currently experiment with using a single transaction call for > installation, which would solve this as rpm would do the ordering. But this > is still work in progress. Thanks for the explanations. But it seems that as long as zypper has modes that splits the initial transaction into indiviual rpm calls, "OrderWithRequires" has to be part of the repo metadata and libzypp needs to understand it.
(In reply to Michael Schröder from comment #5) > Spoke too soon about that "(systemd if systemd)". I think that it would > actually work. The solver ignores it completely (that's why I said it's a > no-op), but the ordering code just looks at the first part of the if. You meant the ordering code of libzypp (dep solver), right ? > (But it's still pretty gross...) Well, that's a workaround due to the way libzypp splits transactions. What would be your final recommendation then ? Still "Suggests:" ? That wouldn't work if the install/update of packages involves rpm only, no ? If that's the case wouldn't "OrderWithRequires:" still be needed ? "Requires: systemd if systemd", even if it looks odd, would be simpler.
I wouldn't recommend "Requires: systemd if systemd" as that relies on the way the ordering code currently deals with boolean dependencies, which might change in the future. My suggestion is to keep the "OderWithRequires" but also to add an additional "Suggests". (Suggests alone would also work with current rpm, but I think the OrderWithRequires is somewhat cleaner.)
Just for completion, note that I already solved the issue with pipewire/systemd with https://build.suse.de/request/show/242183 and a similar SR in Factory, which sets all already installed user services to the preset state when installing systemd (just as we already do with system services) so it doesn't matter if pipewire is installed first. That means there's no need for a workaround in pipewire and also afaik there's no package currently requiring this. Still I reported this issue to document the problem with %systemd_ordering and because I think it would be good to make OrderWithRequires work as expected so future packages can use it if needed.
(In reply to Antonio Larrosa from comment #13) > Still I reported this issue to document the problem with %systemd_ordering > and because I think it would be good to make OrderWithRequires work as > expected so future packages can use it if needed. I agree, OrderWithRequires should work as expected and for that libzypp needs to understand it and it also needs to be included in the repo metadata. I think that's basically what this bug boils down. Meanwhile, as a workaround, %systemd_ordering will be modified (as suggested in comment #12) so it will work as expected with the current implementation of libzypp. I think it's important to get it right even if applying the the preset stuff should be fine without it because there might be other reasons than presets for packages to call systemctl in their scriptlets.
(In reply to Michael Schröder from comment #12) > My suggestion is to keep the "OderWithRequires" but also to add an > additional "Suggests". # rpmbuild -bb SPECS/dummy.spec error: line 11: Unknown tag: Suggests(pre): systemd Hmm how this is supposed to work with "Suggests" then ? Will a plain "Suggests: systemd" work as expected, ie systemd will be installed before the %pre section of the package is executed ?
A plain suggests is enough. The rpm in Factory currently strips the 'pre' as well. I reported that a couple of days ago and it is now fixed.
Would a plain "Suggests" work on SLE15 SP3 too?
(In reply to Michael Schröder from comment #18) > A plain suggests is enough. The rpm in Factory currently strips the 'pre' as > well. I'm not sure to understand that. Do you meant that if rpm sees "Suggests(pre)" it ignores the "pre" constraint ? > I reported that a couple of days ago and it is now fixed. Can you please share the link ? maybe that will shed some light. But will rpmbuild be fixed too so building package with "Suggests(pre)" is possible ? Thanks.
(In reply to Franck Bui from comment #20) > Do you meant that if rpm sees "Suggests(pre)" it ignores the "pre" > constraint ? No, I'm saying that rpm currently strips the "pre" in "OrderWithRequires(pre)". If you check the data in the built rpm packages, the "pre" hint is missing. > Can you please share the link ? maybe that will shed some light. https://github.com/rpm-software-management/rpm/issues/1703 > > But will rpmbuild be fixed too so building package with "Suggests(pre)" is > possible ? We could do that, but I don't really see the need. The "pre" is simply a hint to the ordering code that it should not break this dependency if there is a cycle. So it should not make a difference most of the time. Just use "Suggests: systemd" without the "pre".
(In reply to Antonio Larrosa from comment #19) > Would a plain "Suggests" work on SLE15 SP3 too? I guess "Suggests" works on all supported distros (including SLE12-SP*) so it should be a valid workaround as long as libzypp/zypper is used and there's no dependency cycle to break. Regarding rpm, it's not really clear to me whether "OrderWithRequires:" is understood by all versions of rpm shipped by all maintained distros. But it should be understood at least on SLE15-SP3/Factory. The "pre" is incorrectly ignored but I guess it's only useful in case there're cycles to resolve like with zypper and "Suggests:".
Workaround submitted to Factory: sr#903200. I'll fix SLE and Leap soon.
This is an autogenerated message for OBS integration: This bug (1187332) was mentioned in https://build.opensuse.org/request/show/903200 Factory / systemd-rpm-macros
Closing it.
Hm, why has this been closed ? Is the workaround which consists in using Suggests: no more needed ?
(In reply to Franck Bui from comment #26) > Hm, why has this been closed ? > > Is the workaround which consists in using Suggests: no more needed ? Sorry I oversaw 'fix SLE and Leap soon'. This is still needed. Shall I repoen and assign it to you?
.
No, this should be assigned to those who are supposed to make "OrderWithRequires:" work reliably when the system is updated with "zypper up" (for example). So I guess this belongs to the zypper team.
# maintenance_jira_update_notice openSUSE-RU-2021:2899-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1186282,1187332 CVE References: JIRA References: Sources used: openSUSE Leap 15.3 (src): systemd-rpm-macros-8-7.18.1
# maintenance_jira_update_notice SUSE-RU-2021:2899-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1186282,1187332 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): systemd-rpm-macros-8-7.18.1 SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): systemd-rpm-macros-8-7.18.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
# maintenance_jira_update_notice openSUSE-RU-2021:1226-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1186282,1187332 CVE References: JIRA References: Sources used: openSUSE Leap 15.2 (src): systemd-rpm-macros-8-lp152.8.16.1
# maintenance_jira_update_notice SUSE-RU-2021:2986-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1186282,1187332 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Server 12-SP5 (src): systemd-rpm-macros-8-10.28.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.