Project

General

Profile

Actions

action #128123

closed

coordination #130072: [epic] Handle openQA adaptions in Yam squad - SLE 15 SP6

Handle vendor change issues in automation for migration cases that with PackageHub installed

Added by zoecao 11 months ago. Updated 9 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2023-04-21
Due date:
% Done:

0%

Estimated time:

Description

Motivation:
It happens that if migration with PackageHub, some packages' vendor would change, the vendor of packages from SLE products repos is SUSE, and the vendor of packages from PackageHub repo is openSUSE. See the case:
http://openqa.suse.de/tests/10953226#step/resolve_dependency_issues/13

Need to handle the vendor change issue for this kind of warning. This might the way:
https://en.opensuse.org/SDB:Vendor_change_update#Full_repository_Vendor_change
like:
You can define a list of repositories having different "vendors" as equivalent by creating a file in the /etc/zypp/vendors.d/ directory with a similar content:

[main]

vendors = suse,opensuse,obs://build.suse.de,Packman,http://packman.links2linux.de

Adding BREAK_DEPS=1 to the case setting can also resolve it, but this setting may make us miss the real file conflict bugs.


Files

Actions #1

Updated by openqa_review 11 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15sp2_ltss_pscc_basesys-srv-phub_def_full
https://openqa.suse.de/tests/11022688#step/resolve_dependency_issues/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions #2

Updated by shukui 11 months ago

Actions #3

Updated by zoecao 11 months ago

  • File vendor_change_screenshot_1.png added
  • File vendor_change_screenshot_2.png added
  • File vendor_change_screenshot_3.png added

I have manually tested the workaround for handling vendor change based on this doc:
https://en.opensuse.org/SDB:Vendor_change_update#Full_repository_Vendor_change
Update the result here:

  • Using the yast2 UI, it works fine, steps as below:
  • 1. During migration by yast, if see conflicts, screenshot as below
  • 2. Click "Packages", the conflict will popup, check the content of the conflict, confirm it is about vendor change.
  • 3. Click "Cancel" on the popup window to do workaround (may need to click several times, it depends on the number of packages that would change vendor)
  • 4. Click "View" -> "Repositories" , choose the repo that you want to switch and click "Switch system packages" to the versions in this repository", (then the system will use the packages in this repo, evenif the other repos have a higher package version), see screenshot for this step PS: I suppose we need to switch to all the modules' update repo except "PackageHub" repos, because we don't which package would change vendor and which repo it come from.
  • 5. After done with switch the repos, click "Accept" and then click "Continue" to accept the changes, screenshot: then the conflict warning about vendor change will disappear, the system can continue to do migration.

And I also tried the way of creating a file in the /etc/zypp/vendors.d/ directory with content:
[main]

vendors = suse,opensuse

it doesn't work, maybe because the content I wrote is incorrect, anyway, we could use the yast2 UI way.

Actions #4

Updated by JERiveraMoya 11 months ago

  • Target version deleted (Current)
  • Parent task set to #121876

Updated by zoecao 10 months ago

I asked yast developers about how to allow vendor change in YaST UI, below is the steps:

  1. During migration by yast, if see conflicts, click "Packages", see screenshot as below:
  2. Then the conflicts will popup, need to cancel them one by one to go into the YaST Software. ==
  3. Click the "Options" in the menu, and then click "yast2_ui_config_vendor_change_5.png":
  4. Then click the "Accept" and click "Continue" (twice in my manually test, one for packages changes one for Packagehub product) for the changes:
  5. It would go into the Installation Overview without the conflicts (of the vendor changes).
Actions #6

Updated by zoecao 10 months ago

  • File deleted (vendor_change_screenshot_1.png)
Actions #7

Updated by zoecao 10 months ago

  • File deleted (vendor_change_screenshot_2.png)
Actions #8

Updated by zoecao 10 months ago

  • File deleted (vendor_change_screenshot_3.png)
Actions #9

Updated by leli 10 months ago

  • Status changed from New to Workable
  • Target version set to Current
Actions #10

Updated by leli 10 months ago

  • Status changed from Workable to In Progress
  • Assignee set to leli
Actions #12

Updated by leli 10 months ago

For step3, it should be 'Click the "Options" in the menu, and then click "allow vendor change"'.

Actions #13

Updated by JERiveraMoya 10 months ago

  • Parent task changed from #121876 to #130072
Actions #14

Updated by JERiveraMoya 9 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF