Looks like the .so files were mistakenly moved from the devel package to the lib package.  If they need to be in the lib package for some reason, there needs to be conflicts to ensure smooth upgrade.

Assignee: bugsquad => ghibomgx
CC: (none) => thierry.vignaud

I think it's right in the library, not in devel, because the LLVMgold.so it's not a devel library, but a plugin for the gold linker:

http://llvm.org/docs/GoldPlugin.html

Adding Conflicts: %{libname_devel} < 11.0.1-2.rc2.2, should fix, like in the attached diff.

Created attachment 12193 [details]
fix for LLVMgold.so conflicts

Thierry, can you validate the attached fix?

*** Bug 28449 has been marked as a duplicate of this bug. ***

CC: (none) => olelukoie

(Please set the status to 'assigned' if you are working on it)

Note that: on Mageia 8 these files are owned by:
$ urpmf -f /usr/lib64/LLVMgold.so
lib64llvm11.0-11.0.1-4.2.mga8.x86_64:/usr/lib64/LLVMgold.so

$ urpmf -f /usr/lib64/libLTO.so                                                  
lib64llvm11.0-11.0.1-4.2.mga8.x86_64:/usr/lib64/libLTO.so
lib64llvm11.0-11.0.1-4.2.mga8.x86_64:/usr/lib64/libLTO.so.11

Reporter mentions owner in Mageia 7 with -ddevel package.

Summary: Conflict file /usr/lib64/LLVMgold.so => llvm-11.0 mga8 packages conflicts with mga7 llvm-devel packages when updating MGA7 to MGA8
Blocks: (none) => 28393
Source RPM: lib64llvm11.0-11.0.1-2.rc2.2.mga8.x86_64 => llvm-11.0.1-4.2.mga8.src.rpm
Keywords: (none) => FOR_ERRATA8
CC: (none) => ouaurelien

@tv can you look at this, please?

https://wiki.mageia.org/en/Mageia_8_Errata#Various_upgrade_issues

CC: (none) => fri
Keywords: FOR_ERRATA8 => IN_ERRATA8

I ran into this problem today while upgrading from Mageia 7 to Mageia 8 using a DVD
Work around was to get from the installer UI to the console using Ctrl-Alt-F2
Then chroot to the mount point which in my case was /mnt
Then I ran urpme lib64llvm-devel
After that completed I used Ctrl-Alt-F7 to switch back to the installer UI. Note that it may take a little time to respond if the it is busy.
I then clicked OK at the error warning and followed the steps to continue.

CC: (none) => rihoward1

Follow up from my Comment10 where I had an error in upgrading from Mageia 7 to Mageia 8.
The error message contained:

file /usr/lib64/LLVMgold.so from install of lib64llvm11.0.1-4.2.mga8_x86_64 conflicts with file from package lib64llvm-devel-8.0.0.0-1.1.mga7.x86_64


file file /usr/lib64/libLTO.so from install of lib64llvm11.0.1-4.2.mga8_x86_64 conflicts with file from package lib64llvm-devel-8.0.0.0-1.1.mga7.x86_64


Note that the Mageia 7 version of the lib64llvm-devel package was involved. Possibly that needs a fix so that people can update their Mageia 7 before upgrading to Mageia 8

Upgrade stopper

Severity: normal => critical
Priority: Normal => High

This seems fixed in Cauldron but not in Mageia 8.

This is at least the most STOPPER from upgrading Mageia 7 installation with
-devel.mga7 packages. As we always recommend to remove such packages before migrating, I really doubt inexperienced users install such packages.

In a Mageia 7 system with a Nvidia Geforce GTX 670 with nvidia-current driver, I don't have these packages installed:
- lib64llvm-devel-8.0.0.0-1.1.mga7.x86_64
Not by default.

This is far from a real blocker for mainly used Mageia setup.
Can someone contradict me?

I believe mgaapplet neither remind users to remove packages (at least could tell to read release notes section on upgrading), nor it does remove devel packages itself...

IMO both that could be enhanced but that is separate...

What i mean is: user see mgaapplet offering to updgrade and happily let it...

BTW, is it OK to have kernel-devel packages?
Because IIRC they are required for nvidia.

(In reply to Morgan Leijström from comment #14)
> I believe mgaapplet neither remind users to remove packages (at least could
> tell to read release notes section on upgrading), nor it does remove devel
> packages itself...
> 
> IMO both that could be enhanced but that is separate...
> 
> What i mean is: user see mgaapplet offering to updgrade and happily let it...
> 
> BTW, is it OK to have kernel-devel packages?
> Because IIRC they are required for nvidia.

Yeah. at least, only -devel rpm installed should be related to nvidia stuff on such systems. Others -devel ones are for developpers/packagers that SHOULD aware of this, like 32bits stuff.

My two cents.

Mageia 7 Plasma x86_64

# rpm -qa | grep llvm
lib64llvm8.0-8.0.0-1.1.mga7
llvm-8.0.0-1.1.mga7
lib64llvm-devel-8.0.0-1.1.mga7

# urpmi --auto-update --download-all --auto --test
Installation is possible

Now, really playing it:
# urpmi --auto-update --download-all --auto

Installation failed:    file /usr/lib64/LLVMgold.so from install of lib64llvm11.0-11.0.1-4.2.mga8.x86_64 conflicts with file from package lib64llvm-devel-8.0.0-1.1.mga7.x86_64
        file /usr/lib64/libLTO.so from install of lib64llvm11.0-11.0.1-4.2.mga8.x86_64 conflicts with file from package lib64llvm-devel-8.0.0-1.1.mga7.x86_64
        libLLVM-11.so()(64bit) is needed by lib64dri-drivers-20.3.4-2.mga8.x86_64
        libLLVM-11.so(LLVM_11)(64bit) is needed by lib64dri-drivers-20.3.4-2.mga8.x86_64
        libglvnd = 1.3.2-16.mga8 is needed by lib64gl1-1.3.2-16.mga8.x86_64
        libglvnd = 1.3.2-16.mga8 is needed by lib64egl1-1.3.2-16.mga8.x86_64
        libglvnd >= 1.3.1-7 is needed by lib64mesagl1-20.3.4-2.mga8.x86_64
        libglvnd >= 1.3.1-7 is needed by lib64mesaegl1-20.3.4-2.mga8.x86_64
        BLABLABLA...

This is NOT OK.
But, the installation can later continue if I do:
# urpme lib64llvm-devel

and 
# urpmi --auto-update --download-all --auto

Please test new llvm package i just pushed in mga8 updates_testing

CC: (none) => mageia

we need to ensure it updates fin from mga 7-> 8 and mga 8-> 8

Assignee: ghibomgx => qa-bugs

After upgrade from Mageia 7 to 8 with testing repos enabled ...
# rpm -qa|grep llvm
llvm-plugins-11.0.1-4.2.1.mga8
llvm-static-11.0.1-4.2.1.mga8
llvm-test-11.0.1-4.2.1.mga8
lib64llvm11.0-11.0.1-4.2.1.mga8
llvm-11.0.1-4.2.1.mga8
lib64llvm-devel-11.0.1-4.2.1.mga8

Validating the update.

CC: (none) => davidwhodgins, sysadmin-bugs
Whiteboard: (none) => MGA8-64-OK
Keywords: (none) => validated_update

How exactly the fix to the SPEC file works? For instance I see two same files/libraries belonging to two different packages, e.g., doing:

rpm -qf /usr/lib64/libLTO.so

returns:

llvm-plugins-11.0.1-4.2.1.mga8
lib64llvm11.0-11.0.1-4.2.1.mga8

as well as:

rpm -qf /usr/lib64/libRemarks.so

returns:

llvm-plugins-11.0.1-4.2.1.mga8
lib64llvm11.0-11.0.1-4.2.1.mga8

CC: (none) => ghibomgx

rpm allows one file to be owned by more than one package if, and only if, all
versions of the file are identical. If they are not identical, only one of those
packages may be installed.

So the question becomes which version of the file is correct? Then either
remove the version of the file included in the other package(s) and have
the other package require the one where it's kept, or make them identical.

i used 2 commits from cauldron:

https://svnweb.mageia.org/packages/cauldron/llvm/current/SPECS/llvm.spec?r1=1695180&r2=1696062
https://svnweb.mageia.org/packages/cauldron/llvm/current/SPECS/llvm.spec?r1=1696062&r2=1697999

Well, I was seeking for information about a common way on how to solve this kind of problems in general. AFAIK actually the problem arise in the package transaction when a file is moved from one package to another package of newer release. If you install the package in the same transaction, or by hand having all the packages available, the problems doesn't occur. Viceversa when packages are retrieved by urpmi, by the expanded dependencies, it occurs. Unpredictable behaviour is when you use in this case urpmi with split-length=1 or 0. 

In this way of fixing, if I understand right, we provided an intermediate package (package-plugins), Required, which duplicates the "offending" files, exploiting, as David said, the "feature" of rpm that, when a file is exactly the same, byte by byte (or empty) in both old and newer package, no error about file overlapping would ever occur. In this way, both old and new package would find the same file trough transactions.

Usually another way we used to fix similar problems, was to add to the older packagename (but newer version) a "Conflicts: newerpackage < [turning_point_version]" where "[turning_point_version]" is the package version where the file moving arose, and newerpackage is the name of package where the file was moved to. Of course, if we backport a newer version of the newer package (without the file moving) to an older distro (e.g. mga7), the "[turning_point_version]" is floating forward, and thus should be refreshed to the next immediate release, where the file moving occurs.

Advisory:
========================

Updated llvm packages fix Mageia 7 to 8 upgrade

The llvm packages have been updated to prevent errors
'file /usr/lib64/LLVMgold.so from install of lib64llvm11.0-11.0.1-4.2.mga8.x86_64 conflicts with file from package lib64llvm-devel-8.0.0-1.1.mga7.x86_64' and
'file /usr/lib64/libLTO.so from install of lib64llvm11.0-11.0.1-4.2.mga8.x86_64 conflicts with file from package lib64llvm-devel-8.0.0-1.1.mga7.x86_64'

References:
https://bugs.mageia.org/show_bug.cgi?id=28007
========================

Updated packages in 8/core/updates_testing:
========================
llvm-plugins-11.0.1-4.2.1.mga8
llvm-static-11.0.1-4.2.1.mga8
llvm-test-11.0.1-4.2.1.mga8
lib(64)llvm11.0-11.0.1-4.2.1.mga8
llvm-11.0.1-4.2.1.mga8
lib(64)llvm-devel-11.0.1-4.2.1.mga8
llvm-doc-11.0.1-4.2.1.mga8
llvm-googletest-11.0.1-4.2.1.mga8

from SRPM:
llvm-11.0.1-4.2.1.mga8.src.rpm

Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0052.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

In Errata marked as fixed by update