Bugzilla – Bug 1220091
[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'
Last modified: 2024-06-19 10:12:37 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)
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
i would not add Obsoletes ... I would ask customers to select the "deinstall libopenssl1_1-devel" option somehow.
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?
In tumbleweed we did not do that, we asked folks to do it manually. I am kind of undecided.
(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
(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.
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?
(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.
@Marcus, where do you think it would be better to document this? TIA I'm assigning this bug to Otto.
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.
Adding Tanja and Lukash
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.
Done in https://gitlab.suse.de/documentation/release-notes-sles/-/commit/ee9fdb581d71f9b8624dc8cdd9e5f9d99d72ea01
Verify here, thanks.