On Sat, May 21, 2022 at 8:49 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 21.05.2022 15:27, Neal Gompa wrote: ...
If you're splitting packages, you should have Obsoletes: on each package being split out so that libsolv considers them upgrade candidates.
No, it does not work.
tw:~ # zypper info --obsoletes foo foo-bar
Loading repository data...
Reading installed packages...
Information for package foo:
----------------------------
Repository : local
Name : foo
Version : 1-2
Arch : noarch
Vendor :
Installed Size : 0 B
Installed : Yes
Status : out-of-date (version 1-1 installed)
Source package : foo-1-2.src
Summary : testing subpackage split
Description :
Testing subpackage split
Obsoletes : foo < 1-2
Information for package foo-bar:
--------------------------------
Repository : local
Name : foo-bar
Version : 1-2
Arch : noarch
Vendor :
Installed Size : 0 B
Installed : No
Status : not installed
Source package : foo-1-2.src
Summary : Package split from foo
Description :
Package split from foo
Obsoletes : foo < 1-2
tw:~ # zypper in -r local foo
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following package is going to be upgraded:
foo
1 package to upgrade.
Overall download size: 5.9 KiB. Already cached: 0 B. No additional space will be
used or freed after the operation.
Continue? [y/n/v/...? shows all options] (y):
You can also use Recommends from the old package to have the two others pulled in by default.
Have you tried to actually read this thread?
But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead.
It is not the question here. The question is how to make sure NetworkManager-wifi is installed after update from package version before split. You cannot assume everyone having NetworkManager also has desktop pattern.
So split-alias mentioned by Aaron actually work. My only complain is that it does not work with plain rpm, but then it is not clear how it can be made to work in the first place.
You've basically described a libsolv bug. RPM describes Obsoletes as working specifically in that manner: https://rpm-software-management.github.io/rpm/manual/dependencies.html#obsol...
Per RPM, every package that has a matching Obsoletes: condition should be added to the transaction as an update to replace the old one. So if
Where RPM is supposed to get this information in the first place? RPM does not work with repositories - all that RPM has is the list of packages in the current transaction. At most RPM may abort transaction if something is missing, but in this case nothing is missing at all - "foo" exists both before and after update.
you have foo split into foo and bar, foo and bar should obsolete old foo, so RPM upgrades that package to have both of them.
RPM cannot do it. You start with a system where foo is installed. If you do "rpm -U foo" there is nothing that tells RPM that bar is also "missing". If you already selected "bar" for installation together with "foo" then what you say is irrelevant because decision happened outside of RPM.
So in both cases it is up to higher level package management like libsolv to chose the right packages, and comparing
Provides: NetworkManager:.../libnm-device-plugin-wifi.so
and
Obsoletes: NetworkManager < V-R
in the NetworkManager-wifi, the former is certainly more logical and avoids issues with different V-R in different projects.
The former is a YaST/Zypp specific hack, the latter is *actually* how RPM wants you to do it. Moreover, if you download all the built NM packages and do "rpm -Uvh" on them, RPM would do the right thing. That's the point of using the actual RPM-defined behavior for this. This behavior is compatible with Zypp, YaST, DNF, and any other dependency resolver, whereas your Provides hack only works in YaST/Zypp. -- 真実はいつも一つ！/ Always, there's only one truth!