Bugzilla – Bug 1218096
The migration summary of Packagehub is incorrect when doing migration via yast2
Last modified: 2024-01-08 16:39:32 UTC
Created attachment 871383 [details] y2log_for_packagehub_migration Steps: - Boot SLES15SP5 image, and register the system as well as Packagehub via scc - Fully patch the packages - Perform migration via "yast2 migration" When it comes to Migration Proposal step, I observed the migration path of Packagehub is not correct as below: * Product SUSE Package Hub 15 will be updated Expect result: * Product SUSE Package Hub 15 will be upgraded to SUSE Package Hub 15 SP6 Beta2-202312 See a few steps before of the same case, the migration summary of Packaghub in Migration Target step is correct: https://openqa.suse.de/tests/13077239#step/yast2_migration/5 Please find the attached y2log and screenshot of the summary, and below is the openqa testcase: openQA test in scenario sle-15-SP6-Migration-from-SLE15-SPx-Milestone-x86_64-online_sles15sp5_scc_basesys-srv-python3-desk-phub_def_full_yast_test@64bit fails in [yast2_migration](https://openqa.suse.de/tests/13077239/modules/yast2_migration/steps/11) Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Migration-from-SLE15-SPx-Milestone&machine=64bit&test=online_sles15sp5_scc_basesys-srv-python3-desk-phub_def_full_yast_test&version=15-SP6)
Created attachment 871384 [details] screenshot_of_migration_summary
Created attachment 871442 [details] Relevant part of the y2log (gzipped) The part of y2log that starts with 2023-12-15 04:53:25 <1> susetest(2766) [Ruby] bin/y2start(<main>):22 y2base called with ["migration", "ncurses", "-name", "YaST2", "-icon", "yast"] and contains "Package Hub".
This might have something to do with it: > 2023-12-15 04:53:36 <1> susetest(2766) [Ruby] > modules/AddOnProduct.rb(renamed_by_libzypp?):2102 > Search sle-module-packagehub-subpackages -> SLES rename in libzypp: { > "Leap <= 15.3"=>["SLES"], > "openSUSE <= 15.3"=>["SLES"], > "SLES-SP5"=>["SLES"], > "SUSE_SLE"=>["SLES"], > "SUSE_SLE-SP5"=>["SLES"], > "sle-module-adv-systems-management"=>["sle-module-basesystem"], > "sle-module-basesystem-SP5"=>["sle-module-basesystem"], > "PackageHub-SP5"=>["PackageHub"], > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > "sle-module-packagehub-subpackages-SP5"=>["sle-module-packagehub-subpackages"], > "sle-module-desktop-applications-SP5"=>["sle-module-desktop-applications"], > "sle-module-server-applications-SP5"=>["sle-module-server-applications"], > "sle-module-python3-SP5"=>["sle-module-python3"]}
Here it still looks good: > 2023-12-15 04:53:36 <1> susetest(2766) > [Ruby] ui/migration_selection_dialog.rb(migration_details):246 > . > Migration Summary > . > - Basesystem Module will be upgraded to Basesystem Module 15 SP6 x86_64. > . > - Desktop Applications Module will be upgraded to Desktop Applications Module 15 SP6 x86_64. > . > - Python 3 Module will be upgraded to Python 3 Module 15 SP6 x86_64. > . > - Server Applications Module will be upgraded to Server Applications Module 15 SP6 x86_64. > . > - SUSE Package Hub 15 will be upgraded to SUSE Package Hub 15 SP6 x86_64. > . > - SUSE Linux Enterprise Server 15 SP5 will be upgraded to SUSE Linux Enterprise Server 15 SP6 x86_64. > . > - The registration server does not offer migrations for Product > Module to ship some SLE subpackages by PackageHub so it will stay unchanged. > We recommend you to check if it's correct and to configure the repositories manually when needed.
Here it's no longer okay: > 2023-12-15 04:54:15 <0> susetest(2766) [Ruby] > binary/Yast.cc(ycp_module_call_ycp_function):401 Append parameter > . > Migration Summary > . > - Product Basesystem Module will be updated to Basesystem Module Beta2-202312 > - Product Desktop Applications Module will be updated to Desktop Applications Module Beta2-202312 > - Product Python 3 Module will be updated to Python 3 Module Beta2-202312 > - Product SUSE Linux Enterprise Server 15 SP5 will be updated to SUSE Linux Enterprise Server 15 SP6 Beta2-202312 > - Product Module to ship some SLE subpackages by PackageHub will be updated to Module to ship some SLE subpackages by PackageHub Beta1-202311 > - Product SUSE Package Hub 15 will be updated > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > - Product Server Applications Module will be updated to Server Applications Module Beta2-202312 > . > - Packages to Update: 328 > - New Packages to Install: 108 > - Packages to Remove: 3 > - Total Size of Packages to Update: 1.5 GiB "Product SUSE Package Hub 15 will be updated" - Okay, the old product name may have been replaced as directed by libzypp (probably coming from SCC) - see comment #3. But the user will want to know the target product name / version that it's updated to. ...unless that is the same as the original; it wouldn't make sense to tell the user "Product SUSE Package Hub 15 will be updated to SUSE Package Hub 15". That might be the case here. I'll keep investigating.
This seems indeed to be the case. Those are the products to upgrade to, as sent by the SCC: > 2023-12-15 04:54:06 <1> susetest(2766) [Ruby] > y2packager/product_reader.rb(available_base_products):124 > all products > [ > . > #<Y2Packager::Product:0x0000558b6c1b7630 @name="sle-module-basesystem", > @short_name="Basesystem-Module", > @display_name="Basesystem Module Beta2-202312", > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LLC <https://www.suse.com/>", > @order=nil, > @installation_package=nil, > @register_target="sle-15-x86_64">, > . > #<Y2Packager::Product:0x0000558b6c1b1140 @name="sle-module-desktop-applications", > @short_name="Desktop-Applications-Module", > @display_name="Desktop Applications Module Beta2-202312", > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LLC <https://www.suse.com/>", > @order=nil, > @installation_package=nil, > @register_target="sle-15-x86_64">, > > #<Y2Packager::Product:0x0000558b6c1aac00 @name="sle-module-python3", > @short_name="Python 3-Module", > @display_name="Python 3 Module Beta2-202312", > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LLC <https://www.suse.com/>", > @order=nil, > @installation_package=nil, > @register_target="sle-15-x86_64">, > . > #<Y2Packager::Product:0x0000558b6bc524b0 @name="SLES", > @short_name="SLES15-SP6", > @display_name="SUSE Linux Enterprise Server 15 SP6 Beta2-202312", > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LLC <https://www.suse.com/>", > @order=200, > @installation_package="skelcd-control-SLES", > @register_target="sle-15-x86_64">, > . > #<Y2Packager::Product:0x0000558b6bc4b480 @name="sle-module-packagehub-subpackages", > @short_name="PackageHub-Subpackages-Module", > @display_name="Module to ship some SLE subpackages by PackageHub Beta1-202311", > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LLC <https://www.suse.com/>", > @order=nil, > @installation_package=nil, > @register_target="">, > > #<Y2Packager::Product:0x0000558b6bc44f68 @name="PackageHub", > @short_name="SUSE-PackageHub-15", > @display_name="SUSE Package Hub 15", > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LINUX Products GmbH, Nuernberg, Germany", > @order=nil, > @installation_package=nil, > @register_target="sle-15-x86_64">, > . > #<Y2Packager::Product:0x0000558b6bc32818 @name="sle-module-server-applications", > @short_name="Server-Applications-Module", > @display_name="Server Applications Module Beta2-202312", > @version="15.6-0", > @arch=:x86_64, > @category=:addon, > @vendor="SUSE LLC <https://www.suse.com/>", > @order=nil, > @installation_package=nil, > @register_target="sle-15-x86_64">] So the target product PackageHub 15.6-0 has a "display_name" (i.e. that's what should be displayed for the user) "SUSE Package Hub 15". Since the old (already installed) product has the same "friendly_name" (the one to display for the user) "SUSE Package Hub 15", the information line for the user would be > Product SUSE Package Hub 15 will be updated to SUSE Package Hub 15" which would be awkward and confusing, so it's shortened to just > Product SUSE Package Hub 15 will be updated which is the observed behavior. Since that's the information that the SCC sends, that's what the YaST migration displays; it behaves as specified. Probably the decision to name that product just "SUSE Package Hub 15" and no longer (?) include version numbers ("SUSE Package Hub 15 SP6") came from product management.
From the YaST perspective, this works as designed; it's not a bug. -> WORKSFORME or INVALID. Ladislav, any more input from your side?
But let's also hear the SCC team if they have anything to add here.
The product name is defined in the PackageHub product package (PackageHub-release RPM). Currently it is "SUSE Package Hub 15" without any version specified. You can check that with the "zypper products" call.
I agree with Ladislav, that value seems to come from the release package, and not SCC. Because also those names with 'Beta2-202312' are not coming from SCC. But this seems to be a very minor cosmetic issue to me, which only beta testers would see.
I think this might be it: https://build.suse.de/package/show/SUSE:Backports:SLE-15-SP6/000product Change log: https://build.suse.de/package/view_file/SUSE:Backports:SLE-15-SP6/000product/PackageHub-release.changes?expand=1 > ------------------------------------------------------------------- > Wed Aug 2 13:20:35 UTC 2023 - Wolfgang Engel <wolfgang.engel@suse.com> > . > - Fix typos in product file > > ------------------------------------------------------------------- > Sat Jul 22 10:05:00 UTC 2023 - Wolfgang Engel <wolfgang.engel@suse.com> > . >- Initial product definition for SLE-15-SP6 Product definition: https://build.suse.de/package/view_file/SUSE:Backports:SLE-15-SP6/000product/PackageHub.product?expand=1
(In reply to Thomas Schmidt from comment #10) > I agree with Ladislav, that value seems to come from the release package, > and not SCC. Because also those names with 'Beta2-202312' are not coming > from SCC. > But this seems to be a very minor cosmetic issue to me, which only beta > testers would see. OK, in that case I'd say we can close this.
Wolfgang, FYI. I am not sure how this is meant to be; if there should be the service pack number or not.
I reopen it and assign it to Walfgang. I think packagehub has service pack so it is supposed to show in summary.
Hello Wolfgang, Could you please look into this bug.
It looks like that the information "SUSE Package Hub 15" is used either from summary value from either the spec file (PackageHub-release.spec) or product definition (PackageHub.product) and I'm wondering if it should be used that way since the version and service pack level is also defined and more precise. I can change the summary to also state the correct service pack.
Lowering priority to P4.