Bug 1148622 - Broken / incomplete dependencies for libyui9 -> libyui10 upgrade
Broken / incomplete dependencies for libyui9 -> libyui10 upgrade
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P2 - High : Normal (vote)
: ---
Assigned To: Ladislav Slezák
Jiri Srain
https://trello.com/c/JaItPLy4
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-28 17:38 UTC by Ladislav Slezák
Modified: 2021-03-23 09:40 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Upgrade from an older TW snapshot to the latest one (166.11 KB, image/png)
2019-08-28 17:38 UTC, Ladislav Slezák
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ladislav Slezák 2019-08-28 17:38:34 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.
Comment 1 Ladislav Slezák 2019-08-28 17:40:10 UTC
Questions:

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!
Comment 2 Michael Schröder 2019-08-29 09:32:25 UTC
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.
Comment 3 Adam Spiers 2019-08-29 11:31:30 UTC
+1 - I got hit by this yesterday.
Comment 4 Ladislav Slezák 2019-09-02 10:17:29 UTC
(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!
Comment 5 Lukas Ocilka 2019-09-02 11:08:08 UTC
It looks like we have a problem in use-cases. UI (libyui plugins) is not
necessary. It's installed just on request.

1. GUI

   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
  
2. TUI

   The same, but probably a base pattern, libyui-ncurses
   Version should behave as above

3. Upgrade

   Upgrade (system upgrade) should work the same, patterns should define
   that they want  libyui-qt-10 or higher

4. Update

   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
   one YaST-UI-10?

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.
Comment 6 Ladislav Slezák 2019-09-02 12:19:28 UTC
(In reply to Lukas Ocilka from comment #5)
> 1. GUI
> 
>    The fact, that libyui-qt is installed, is because some pattern wanted
>    that.

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.
Comment 7 Ladislav Slezák 2019-09-03 07:41:07 UTC
HuHa or Martin, any hints how to solve this?
Comment 8 Stefan Hundhammer 2019-09-03 13:08:50 UTC
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.
Comment 9 Ladislav Slezák 2019-09-03 13:24:38 UTC
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.
Comment 10 Ladislav Slezák 2019-09-03 14:16:30 UTC
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.
Comment 11 Ladislav Slezák 2019-09-05 15:01:29 UTC
I'm experimenting with the dependencies and it seems that adding 

  Obsoletes:      libyui-ncurses-pkg9

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.
Comment 12 Michael Schröder 2019-09-13 13:51:46 UTC
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.
Comment 13 Michael Schröder 2019-09-13 13:53:19 UTC
(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)
Comment 14 Ladislav Slezák 2019-10-16 13:14:35 UTC
The Obsoletes dependencies were added in

- https://github.com/libyui/libyui-qt-pkg/pull/74
- https://github.com/libyui/libyui-ncurses-pkg/pull/29

The upgrade works fine now.