Bugzilla – Bug 1148622
Broken / incomplete dependencies for libyui9 -> libyui10 upgrade
Last modified: 2021-03-23 09:40:25 UTC
Created attachment 816112 [details]
Upgrade from an older TW snapshot to the latest one
This is related to https://bugzilla.suse.com/show_bug.cgi?id=1145963 where we avoided the problem by keeping the libyui at the version 9. But the problem exists in Tumbleweed and we will definitely have the same problem in SLE/Leap at some point in time.
Actually we would like to have the version 10 in SLE15-SP2 but first we need to solve this dependency issue, otherwise it would break at upgrade which is not acceptable.
The problem is that YaST and libyui have these dependencies
("->" means "requires", the name in parenthesis is the providing package):
libyui10 -> yui_backend = 10 (libyui-ncurses10)
yast2-ruby-bindings -> yast2-ycp-ui-bindings
yast2-ycp-ui-bindings - libyui.so.10 (libyui10)
yast2 -> yui_backend (libyui-ncurses9/10)
yast2-packager -> libyui_pkg (libyui-ncurses-pkg9/10, libyui-qt-pkg9/10)
But during the system upgrade only the yast2-ycp-ui-bindings, libyui10 and libyui-ncurses10 packages are installed/upgraded. See the attached screenshot.
I guess we could trigger removing the old version via weakremoval(libyui9) etc... in the base product. But I'm not sure if that would trigger the upgrade for both libyui-qt-pkg10 and libyui-ncurses-pkg10. In theory the solver could upgrade only one of them.
Zypp maintainers, could you help us to solve the dependency/upgrade problem? Thank you!
Change the libyui-X-pkgY package so that it provides "libyui_pkg = Y" instead of just "libyui_pkg" and then add also add a
Conflicts: libyui_pkg < Y
to them so that the plugins stay in sync.
+1 - I got hit by this yesterday.
(In reply to Michael Schröder from comment #2)
> Change the libyui-X-pkgY package so that it provides "libyui_pkg = Y"
> instead of just "libyui_pkg" and then add also add a
> Conflicts: libyui_pkg < Y
> to them so that the plugins stay in sync.
Um, the problem is that there is actually no real conflict. You can have installed both libyui*9 and libyui*10 in parallel, in theory there might other (non-YaST) 3rd party application linked against libyui9. In that case it's fine to have both of them in the system.
We would rather need to fix the "yast2-packager -> libyui_pkg" dependency so it means something like "install libyui-*-pkg* in the same version as the yast2-ycp-ui-bindings is linked against".
The problem is also that "install" dependency is a soft dependency (e.g.
libyui-ncurses-pkg contains "Supplements: packageand(libyui-ncurses:yast2-packager)". And I'm not sure if adding "yast2-packager -> libyui_pkg = 10" dependency would upgrade both libyui-ncurses-pkg and libyui-qt-pkg if they are installed.
Any hints? TIA!
It looks like we have a problem in use-cases. UI (libyui plugins) is not
necessary. It's installed just on request.
The fact, that libyui-qt is installed, is because some pattern wanted that.
This libyui-qt-9 MUST require libyui-9
New libyui-qt-10 MUST require libyui-10
The same, but probably a base pattern, libyui-ncurses
Version should behave as above
Upgrade (system upgrade) should work the same, patterns should define
that they want libyui-qt-10 or higher
And yes, we have a problem in package-update. Solver sees that updating
just a few packages should work because dependencies are fulfilled. Well,
they are not. "Requires" can't work - UI is not mandatory.
Maybe if both libyui-* provided YaST-UI-10 and libyui-10 required at least
5. Two version at the same time
For the reason mentioned in comment #4 we need to have both versions
at the same time. "Conflicts" can't work.
So, 4 and 5 are not solved.
(In reply to Lukas Ocilka from comment #5)
> 1. GUI
> The fact, that libyui-qt is installed, is because some pattern wanted
BTW in GUI also the ncurses packages are installed. (Just to have a fallback
when X does not start for whatever reason.)
> This libyui-qt-9 MUST require libyui-9
> New libyui-qt-10 MUST require libyui-10
That's OK, these dependencies are handled properly.
We actually miss a dependency to enforce at upgrade the libyui-*-pkg in the version which is used by YaST (which is required by yast2-ycp-ui-bindings).
Also the patterns usually use only the soft dependencies (Recommends/Suggests) so the solver is not required to select them.
HuHa or Martin, any hints how to solve this?
Maybe this would help:
libyui10 conflicts libyui-qt-pkg9
libyui10 conflicts libyui-ncurses-pkg9
This would throw out the older pkg widgets when a new libyui base lib is installed.
Yes, if in the end we need to add some conflicts I'd prefer to add them to the *-pkg packages as we can be pretty sure that nobody else except YaST uses them.
Side note: if somebody would like to build testing packages with additional Conflicts/Obsoletes/whatever keep in mind that the packages built in OBS will have a different package vendor and the solver might ignore them at upgrade.
You will need to touch solver.dupAllowVendorChange in /etc/zypp/zypp.conf or use "zypper dup --allow-vendor-change". For upgrade using the YaST installer you could create a vendor file in /etc/zypp/vendors.d, like here https://github.com/yast/yast-migration/blob/afeea3caf58d3195acbcc0b411e2b78018da3f21/src/lib/migration/main_workflow.rb#L51-L57 we do for the openSUSE (Leap) => SUSE (SLE) packages.
I'm experimenting with the dependencies and it seems that adding
to libyui-ncurses-pkg (and similar to libyui-qt-pkg) does the trick and upgrades libyui-*-pkg9 to libyui-*-pkg10.
The only missing part is that the old libyui9 and libyui-qt9 and libyui-ncurses9 are kept in the system, but that could be solved by adding "Provides: weakremover(libyui9)" to the products.
Well, that's basically "we're switching from libyui-ncurses-pkg9 to libyui-ncurses-pkg", i.e. you're dropping the version suffix.
That might not be a bad idea, as the ui bindings also are not versioned.
(And don't worry about the orphaned libraries, they will be automatically removed when you do a zypper dup and the names no longer exist in the repository)
The Obsoletes dependencies were added in
The upgrade works fine now.