Description of problem: When upgrading Mageia 5 to Mageia 6 cauldron I see the following error message: Installation failed: file /usr/lib64/libpq.so.5.7 from install of lib64pq5.7-9.4.12-1.mga6.x86_64 conflicts with file from package lib64pq5-9.4.12-1.mga5.x86_64 This package is needed by mariadb package and as such, is a dependency of many other packages. Version-Release number of selected component (if applicable): lib64pq5.7-9.4.12-1.mga6.x86_64 How reproducible: Always. Steps to Reproduce: 1. Start with a Mageia 5 system that has the package lib64pq5 installed. 2. Remove the Mageia 5 repositories. 3. Add the Mageia 6 (cauldron) repositories with the command: urpmi.addmedia --urpmi-root "$ROOT_CAULDRON" --distrib 'http://ftp.free.fr/mirrors/mageia.org/distrib/cauldron/x86_64/' 4. Up date the system with "urpmi --auto-update".
It looks like the conflict was fixed by neoclust in http://svnweb.mageia.org/packages/cauldron/postgresql9.4/current/SPECS/postgresql9.4.spec?r1=1063850&r2=1065817&pathrev=1101660, but then since pgsql 9.4.12 was pushed as an update to mga5, that Obsoletes is no longer suitable.
Version: Cauldron => 6Keywords: (none) => Junior_jobAssignee: bugsquad => mageiaSource RPM: lib64pq5.7-9.4.12-1.mga6.x86_64 => postgresql9.4-9.4.12-1.mga6CC: (none) => pkg-bugs
(In reply to PC LX from comment #0) > Description of problem: > > When upgrading Mageia 5 to Mageia 6 cauldron I see the following error > message: > Installation failed: file /usr/lib64/libpq.so.5.7 from install of > lib64pq5.7-9.4.12-1.mga6.x86_64 conflicts with file from package > lib64pq5-9.4.12-1.mga5.x86_64 > > This package is needed by mariadb package and as such, is a dependency of > many other packages. > Why would mariadb require a postgresql lib ? (In reply to Rémi Verschelde from comment #1) > It looks like the conflict was fixed by neoclust in > http://svnweb.mageia.org/packages/cauldron/postgresql9.4/current/SPECS/ > postgresql9.4.spec?r1=1063850&r2=1065817&pathrev=1101660, but then since > pgsql 9.4.12 was pushed as an update to mga5, that Obsoletes is no longer > suitable. Should we push a quick fix to caulron/mga6 updates(_testing) with bumped Obsoletes to help upgraders ?
CC: (none) => tmb
(In reply to Thomas Backlund from comment #2) > (In reply to PC LX from comment #0) > > This package is needed by mariadb package and as such, is a dependency of > > many other packages. > > Why would mariadb require a postgresql lib ? Good question! These are the messages I get when trying the update: Installation failed: file /usr/lib64/libpq.so.5.7 from install of lib64pq5.7-9.4.12-1.mga6.x86_64 conflicts with file from package lib64pq5-9.4.12-1.mga5.x86_64 libgdal.so.20()(64bit) is needed by mysql-workbench-6.3.9-1.mga6.x86_64 libmarblewidget-qt5.so.26()(64bit) is needed by lib64digikamcore5-1:5.5.0-2.mga6.x86_64 libpoppler-qt5.so.1()(64bit) is needed by okular-2:16.12.3-2.mga6.x86_64 libqmobipocket.so.2()(64bit) is needed by okular-2:16.12.3-2.mga6.x86_64 libchromaprint.so.1()(64bit) is needed by kid3-core-3.4.5-1.mga6.x86_64 libKF5JSApi.so.5()(64bit) is needed by lib64okularcore7-2:16.12.3-2.mga6.x86_64 libpoppler-qt5.so.1()(64bit) is needed by kfilemetadata-5.32.0-3.mga6.x86_64 mariadb-client(x86-64) >= 10.1.24-1.mga6 is needed by mariadb-bench-10.1.24-1.mga6.x86_64 libKF5kipiplugins.so.5.5.0()(64bit) is needed by kipi-plugins-piwigo-1:5.5.0-2.mga6.x86_64 kdelibs4support is needed by gwenview-2:16.12.3-2.mga6.x86_64 libbaloofiles.so.4()(64bit) is needed by (installed) lib64gwenviewlib4-2:4.14.3-2.mga5.x86_64 libkfilemetadata.so.4()(64bit) is needed by (installed) kfilemetadata-4.14.3-1.mga5.x86_64 libnepomukcore.so.4()(64bit) is needed by (installed) amarok-3:2.8.0-6.mga5.x86_64 Command exited with non-zero status 12 The packages mariadb-client (and mariadb-bench) are mentioned and that probably is the source of my mistake. > (In reply to Rémi Verschelde from comment #1) > > It looks like the conflict was fixed by neoclust in > > http://svnweb.mageia.org/packages/cauldron/postgresql9.4/current/SPECS/ > > postgresql9.4.spec?r1=1063850&r2=1065817&pathrev=1101660, but then since > > pgsql 9.4.12 was pushed as an update to mga5, that Obsoletes is no longer > > suitable. > > Should we push a quick fix to caulron/mga6 updates(_testing) with bumped > Obsoletes to help upgraders ? That would be much appreciated by this upgrader. :)
(In reply to Thomas Backlund from comment #2) > Should we push a quick fix to caulron/mga6 updates(_testing) with bumped > Obsoletes to help upgraders ? Yes, I just pushed postgresql9.4-9.4.12-1.1.mga6 to core/updates_testing, with these changes: http://svnweb.mageia.org/packages/cauldron/postgresql9.4/current/SPECS/postgresql9.4.spec?r1=1109724&r2=1109723&pathrev=1109724 As much as I hate using %{version}-%{release} in Obsoletes, I think it's one valid use case of it here as we don't want the upgrade path to break next time a pgsql version update is made for Mageia 5. Do we need an advisory + assign to QA, or will you move it directly to core/updates?
Assignee: mageia => rverschelde
The wrong question is being asked. The correct question is where|how was the reporter able to install lib64pq5-9.4.12-1.mga5.x86_64. The latest Official for Mga5 is ftp://mirrors.kernel.org/mageia/distrib/5/SRPMS/core/updates/postgresql9.4-9.4.9-1.mga5.src.rpm Which is properly handled in Mga5 to Mga6 upgrades. This bug is caused by the user and should the invalidated.
CC: (none) => cae
(In reply to Charles Edwards from comment #5) > The wrong question is being asked. > > The correct question is where|how was the reporter able to install > lib64pq5-9.4.12-1.mga5.x86_64. > The latest Official for Mga5 is > ftp://mirrors.kernel.org/mageia/distrib/5/SRPMS/core/updates/postgresql9.4-9. > 4.9-1.mga5.src.rpm > > Which is properly handled in Mga5 to Mga6 upgrades. > > This bug is caused by the user and should the invalidated. Yes and no: 9.4.12-1.mga5 // core-updates_testing (Mga, 5, x86_64) 9.4.9-1.mga5 // core-updates (Mga, 5, x86_64) 9.4.7-1.mga5 // core-updates (Mga, 5, x86_64) So PC LX installed the version from core/updates_testing, but assuming it's going to be validated, the push fixed for Mageia 6 is still necessary.
Are you saying that rpms in *_testing will be fully supported. It was|is my understanding *_testing Is "Use at your own risk" and are supported Only when|if they are moved to /updates/ or /backports/
It's a security update that will land in updates: https://bugs.mageia.org/show_bug.cgi?id=20842
Of course we could push the mga6 "updated obsoletes" as part of the update to keep them in sync...
This issue is solved. The package updated without problems. # rpm -q lib64pq5.7 lib64pq5.7-9.4.12-2.mga7
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Be careful, you are on Mageia 7, new cauldron
Oops, thanks for the warning. Completely missed that 7!
Reopening as David doesn't want us to push this fix as part of bug 20842, so I need a bug report for it.
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
Advisory: ========= Updated postgresql9.4 package fixes upgrade path from Mageia 5 This upgrade fixes a packaging issue when upgrading from Mageia 5 with postgresql9.4 >= 9.4.12 installed. RPMs in core/updates_testing: ============================= libpq5-9.4.12-1.1.mga6 libecpg9.4_6-9.4.12-1.1.mga6 postgresql9.4-server-9.4.12-1.1.mga6 postgresql9.4-docs-9.4.12-1.1.mga6 postgresql9.4-contrib-9.4.12-1.1.mga6 postgresql9.4-devel-9.4.12-1.1.mga6 postgresql9.4-pl-9.4.12-1.1.mga6 postgresql9.4-plpython-9.4.12-1.1.mga6 postgresql9.4-plperl-9.4.12-1.1.mga6 postgresql9.4-pltcl-9.4.12-1.1.mga6 postgresql9.4-plpgsql-9.4.12-1.1.mga6 SRPMs in core/updates_testing: ============================== postgresql9.4-9.4.12-1.1.mga6
Assignee: rverschelde => qa-bugsBlocks: (none) => 20842
Advisory uploaded.
Whiteboard: (none) => advisory
Installs fine on Mageia 6 x86_64, no functional change apart from Obsoletes fix, validating.
Keywords: Junior_job => validated_updateWhiteboard: advisory => advisory MGA6-64-OKCC: (none) => sysadmin-bugs
Thanks for handling this Rémi. Note that the separate bug isn't about what I want, it's that we don't handle completely unrelated issues with no overlap (and not even the same kind of advisory, bugfix vs. security) in the same bug for pushing an update.
We just disagree on them being unrelated ;) The security update triggers the need for a bugfix in Mageia 6, so for me it made sense to push them together. But I'm fine keeping them separate too.
No they're totally unrelated. The Mageia 5 update only fixes security issues, the Mageia 6 update only fixes a packaging bug. I see this one hasn't been pushed yet and the other has though. Sigh :o(
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGAA-2017-0051.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED