Bug 21107 - different rpm checksums between mga5 and mga6 generate conflicts
Summary: different rpm checksums between mga5 and mga6 generate conflicts
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: Mageia 6
Assignee: RPM stack maintainers
QA Contact:
URL:
Whiteboard:
Keywords: FOR_ERRATA6
Depends on:
Blocks:
 
Reported: 2017-06-18 19:00 CEST by Chris Denice
Modified: 2020-09-23 00:29 CEST (History)
4 users (show)

See Also:
Source RPM: rpm-4.13.0.1-2.mga6.src.rpm
CVE:
Status comment:


Attachments

Description Chris Denice 2017-06-18 19:00:47 CEST
Description of problem:

After installing mga5 in a chroot, and trying to upgrade to mga6, I get tons of conflicts due to different packages installing the same file. Example:

 file /usr/include/xkbcommon/xkbcommon-keysyms.h from install of lib64xkbcommon-devel-0.7.1-1.mga6.x86_64 conflicts with file from package libxkbcommon-devel-0.4.3-1.mga5.i586

On the mailing list, Yuri found the issue:

"I guess it is caused mostly by the new checksum algo (SHA-). In your mga5 system the rpm db uses md5 digests, but mga6 packages, as I see, uses sha checksum, so even identical files are not identical for rpm."

How do we solve this? Shall we explicitly add "Conflicts" into the packages or could we find a large scale solution for the mga5 -> mga6 upgrade.

I switch the bug to release critical for obvious reasons.

Cheers,
Chris.
Chris Denice 2017-06-18 19:01:19 CEST

Target Milestone: --- => Mageia 6
Priority: Normal => release_blocker

Comment 1 Jani Välimaa 2017-06-18 19:28:53 CEST
Your example isn't good. We don't support having both x86_64 and i586 devel pkgs installed simultaneously. In that case, there's a conflict and I'd say it's not a bug.

CC: (none) => jani.valimaa

Comment 2 Jani Välimaa 2017-06-18 19:33:51 CEST
But sure there're pkgs which are really shipping identical files. For example sddm and lightdm. Both pkgs ships identical /etc/dbus-1/system.d/org.freedesktop.DisplayManager.conf. File itself hasn't changed in ages.
Comment 3 Charles Edwards 2017-06-18 19:51:43 CEST
I do not know why he used that conflict.

The ones in question and those that brought the response from Yuri were for 
shiboken-devel|python3-shiboken-devel which included identical files, and pyside|python3-pyside which included identical files.

Because rpm in Mga6 and Mga5 differ in the checksum used conflicts could occur 
during upgrade because the files are flaged as conflicts.
If upgraded in the same transaction there would be no conflict.

CC: (none) => cae

Comment 4 Chris Denice 2017-06-18 20:00:11 CEST
Ok, but as I said, that's an example among others, the issue is there.

Is this one ok?

file /usr/share/libpreludedb/classic/pgsql-update-14-5.sql from install of preludedb-pgsql-3.1.0-1.mga6.x86_64 conflicts with file from package preludedb-mysql-1.0.1p1-14.mga5.x86_64



As an aside remark, I did not know that "We don't support" having both i586 and x86_64 devel packages installed. That sounds very weird because such a situation is very easy to reach: core_i586 is activated by default on any x86_64 install. If having installed one i586 devel package on a x86_64 install breaks an upgrade, well, that is really not nice :(
Comment 5 Chris Denice 2017-06-18 20:01:04 CEST
@Charles: because I am not yet aware of all of what "We do not support" :)
Comment 6 Marja Van Waes 2017-06-19 15:58:35 CEST
(In reply to Chris Denice from comment #4)
> Ok, but as I said, that's an example among others, the issue is there.
> 
> Is this one ok?
> 
> file /usr/share/libpreludedb/classic/pgsql-update-14-5.sql from install of
> preludedb-pgsql-3.1.0-1.mga6.x86_64 conflicts with file from package
> preludedb-mysql-1.0.1p1-14.mga5.x86_64
> 

Assuming it is, and else there are enough other examples in this report or the related dev ml thread https://ml.mageia.org/l/arc/dev/2017-06/msg00330.html

Assigning to the rpm stack maintainers, in the hope that there is a large scale solution for this in Mga5->6 upgrades, so that it doesn't need to be fixed in every package with a same file (but new checksum) seperately. 


> 
> 
> As an aside remark, I did not know that "We don't support" having both i586
> and x86_64 devel packages installed. That sounds very weird because such a
> situation is very easy to reach: core_i586 is activated by default on any
> x86_64 install. If having installed one i586 devel package on a x86_64
> install breaks an upgrade, well, that is really not nice :(

You can read more about it in bug #13538, comment #5 and comment bug #13538, comment #6

Assignee: bugsquad => rpmstack
CC: (none) => marja11

Comment 7 Marja Van Waes 2017-06-20 21:34:45 CEST
In council meeting tonight it was decided that this isn't a release blocker, because most upgrade conflicts that can be caused by this have already be fixed (else QA team would hit many more upgrade problems).

Priority: release_blocker => High

Comment 8 Marja Van Waes 2017-06-21 12:09:57 CEST
(In reply to Marja van Waes from comment #7)
> In council meeting tonight it was decided that this isn't a release blocker,
> because most upgrade conflicts that can be caused by this have already be
> fixed (else QA team would hit many more upgrade problems).

Should be in the errata, though, both for the related conflicts that QA team may have missed, and for the always expected upgrade problems when both arches of some devel packages are installed

Keywords: (none) => FOR_ERRATA6

Comment 9 Chris Denice 2017-06-23 22:48:48 CEST
Thanks for the news, ok for the optimistic side.

I just hope that the QA team has done enough upgrade on sufficiently different conditions compared to the number of users that will actually upgrade mga5 :-/


In fact, as Charles said, this bug could be at least toned down by minimizing the number of transactions since the conflicts appear only between 2 different transactions!

Maybe this could a fix?
Comment 10 David Walser 2017-06-24 20:15:45 CEST
(In reply to Marja van Waes from comment #8)
> Should be in the errata, though, both for the related conflicts that QA team
> may have missed, and for the always expected upgrade problems when both
> arches of some devel packages are installed

As for the last point about multi-arch devel packages, that doesn't need an errata item, as it's not supported to begin with.

(In reply to Chris Denice from comment #9)
> In fact, as Charles said, this bug could be at least toned down by
> minimizing the number of transactions since the conflicts appear only
> between 2 different transactions! Maybe this could a fix?

I believe Thierry has already changed the default transaction size from 8 to 50 for Mageia 6, so I guess that fix has already been implemented.
Comment 11 David Walser 2017-06-24 20:20:09 CEST
And actually, increasing the transaction size makes triggering Bug 18797 *more* likely, according to Pascal's analysis.
Comment 12 Charles Edwards 2017-06-24 21:18:52 CEST
50 is fine for installs but it can really suck for upgrades.

On upgrades when 1 pkg in a transaction can not be installed then none in that transaction will be installed and that exponentially increases the likelihood that additional transaction will fail.
On 1 of my 5-6 upgrades test Every transaction (100) failed and /var/cache/urpmi
grew from a few MB to 30GB, doubling the size of /.

I think serious consideration should be given to setting the default transaction
size on upgrades to 20.
Comment 13 Aurelien Oudelet 2020-09-19 18:08:50 CEST
Hi,
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.
Comment 14 David Walser 2020-09-23 00:29:12 CEST
Mageia 6 is EOL.

Resolution: (none) => OLD
Component: Release (media or process) => RPM Packages
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.