Bug 1220091

Summary: [Build 57.1] openQA test fails in zypper_migration: file conflict between libopenssl-1_1-devel-1.1.1w-150600.1.4.x86_64 and 'libopenssl-devel > 1.1.1w'
Product: [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP6 Reporter: Chenzi Cao <chcao>
Component: BasesystemAssignee: Lukas Kucharczyk <lukas.kucharczyk>
Status: VERIFIED FIXED QA Contact:
Severity: Normal    
Priority: P1 - Urgent CC: eugenio.paolantonio, jcheung, lukas.kucharczyk, meissner, otto.hollmann, pmonrealgonzalez, swayammitra.tripathy, taroth
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://openqa.suse.de/tests/13549589/modules/zypper_migration/steps/7
Whiteboard:
Found By: openQA Services Priority:
Business Priority: Blocker: Yes
Marketing QA Status: --- IT Deployment: ---
Attachments: zypper.log

Description Chenzi Cao 2024-02-20 04:37:49 UTC
Created attachment 872856 [details]
zypper.log

Steps:
- On SLES15SP3 with addons basesystem module, server applications module, desktop module, development tools module and ltss, and allpatterns installed
- Fully patch the packages
- De-register ltss
- Perform online migration by "zypper migration"

There's a file conflict:

the to be installed libopenssl-1_1-devel-1.1.1w-150600.1.4.x86_64 conflicts with 'libopenssl-devel > 1.1.1w' provided by the to be installed libopenssl-devel-3.1.4-150600.1.3.noarch

Please find the attached zypper.log and the openqa test result as below:

## Observation

openQA test in scenario sle-15-SP6-Migration-from-SLE15-SPx-x86_64-migr_sles15sp3_desk-dev_all@64bit fails in
[zypper_migration](https://openqa.suse.de/tests/13549589/modules/zypper_migration/steps/7)

## Test suite description
Online migration from sles 15 sp3 with addons desktop,dev via zypper migration. Origin system has system role gnome and all patterns. Additionally, rollback is performed after migration.


## Reproducible

Fails since (at least) Build [57.1](https://openqa.suse.de/tests/13549589) (current job)


## Expected result

Last good: [54.1](https://openqa.suse.de/tests/13494392) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Migration-from-SLE15-SPx&machine=64bit&test=migr_sles15sp3_desk-dev_all&version=15-SP6)
Comment 1 Otto Hollmann 2024-02-20 09:40:02 UTC
Zypper is trying to install devel files of both versions.
> libopenssl-1_1-devel-1.1.1w-150600.1.4.x86_64
> libopenssl-devel-3.1.4-150600.1.3.noarch
But that is intentionally not possible.

I think the solution might be to add
> Obsoletes:      libopenssl-1_1-devel
to openssl-3 devel package.
We did it for older versions:

> %package -n libopenssl-3-devel
> ...
> # Needed for clean upgrade from former openssl-1_1_0, boo#1081335
> Obsoletes:      libopenssl-1_1_0-devel
> # Needed for clean upgrade from SLE-12 openssl-1_0_0, bsc#1158499
> Obsoletes:      libopenssl-1_0_0-devel
Comment 2 Marcus Meissner 2024-02-20 11:35:14 UTC
i would not add Obsoletes ...

I would ask customers to select the "deinstall libopenssl1_1-devel" option somehow.
Comment 3 Pedro Monreal Gonzalez 2024-02-22 11:12:36 UTC
The devel files for the different openssl packages are in conflict and this was done on purpose. The Obsoletes mentioned in comment#1 were added to fix this in previous migrations, see this for openssl-1_0_0 and openssl-1_1 in bsc#1081335 and bsc#1158499.

@Marcus, could we use the Obsoletes approach also for openssl-3?
Comment 4 Marcus Meissner 2024-02-22 17:04:30 UTC
In tumbleweed we did not do that, we asked folks to do it manually.

I am kind of undecided.
Comment 5 Pedro Monreal Gonzalez 2024-02-23 16:27:08 UTC
(In reply to Marcus Meissner from comment #4)
> In tumbleweed we did not do that, we asked folks to do it manually.
> 
> I am kind of undecided.

Right, thanks Marcus.

@chcao, could we apply what Marcus suggested? TIA
Comment 6 Chenzi Cao 2024-02-26 02:19:01 UTC
(In reply to Pedro Monreal Gonzalez from comment #5)
> (In reply to Marcus Meissner from comment #4)
> > In tumbleweed we did not do that, we asked folks to do it manually.
> > 
> > I am kind of undecided.
> 
> Right, thanks Marcus.
> 
> @chcao, could we apply what Marcus suggested? TIA

Yes, it's fine for me.
Comment 7 Otto Hollmann 2024-03-01 08:37:34 UTC
My initial idea/proposal was different, but I have no problem with Marcus's suggestion, let's do it this way.

So can this bug be closed? Or do we need to write a TID or documente it somewhere?
Comment 8 Chenzi Cao 2024-03-05 08:41:27 UTC
(In reply to Otto Hollmann from comment #7)
> My initial idea/proposal was different, but I have no problem with Marcus's
> suggestion, let's do it this way.
> 
> So can this bug be closed? Or do we need to write a TID or documente it
> somewhere?

I think it's better to document it somewhere, but I don't where to do it.
Comment 9 Pedro Monreal Gonzalez 2024-03-13 08:25:50 UTC
@Marcus, where do you think it would be better to document this? TIA

I'm assigning this bug to Otto.
Comment 10 Marcus Meissner 2024-03-20 14:38:25 UTC
I think release notes is the best place.

https://jira.suse.com/browse/PED-6571 is the releasenotes jira ticket. We can add some sentences there for the openssl-3 transition perhaps.
Comment 11 Radoslav Tzvetkov 2024-03-28 15:40:43 UTC
Adding Tanja and Lukash
Comment 12 Radoslav Tzvetkov 2024-04-02 10:09:47 UTC
Please indicate the current expectation for fixing the bug using the Target Milestone field. What do we believe is possible? 

In the cases where we do not plan to deliver or cannot guess (!?) please do not enter anything, but you can comment if you wish to provide more details.
Comment 17 Chenzi Cao 2024-06-19 10:12:37 UTC
Verify here, thanks.