Bug 20448 - conflicts in upgrading from mga5 to mga6
Summary: conflicts in upgrading from mga5 to mga6
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: Barry Jackson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-11 11:18 CET by Chris Denice
Modified: 2017-03-12 18:35 CET (History)
2 users (show)

See Also:
Source RPM: eigen3-3.3.3-1.mga6.src.rpm
CVE:
Status comment:


Attachments

Description Chris Denice 2017-03-11 11:18:18 CET
Just did a mga5 upgrade to cauldron on the command line with urpmi. Everything went smooth, up to the usual issues with mirror out-of-sync.

However a few conflicting files appeared, from reasons that I don't understand. For instance:

installing libx11-common-1.6.5-1.mga6.x86_64.rpm lib64vcd0-0.7.24-11.mga6.x86_64.rpm eigen3-devel-3.3.3-1.mga6.noarch.rpm x11-data-xkbdata-2.20-1.mga6.noarch.rpm tor-0.2.9.10-1.mga6.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     ############################################################
Installation failed:    file /usr/include/eigen3/Eigen from install of eigen3-devel-3.3.3-1.mga6.noarch conflicts with file from package eigen3-devel-3.2.2-3.mga5.noarch


How this is possible?
eigen3-devel-3.3.3-1.mga6.noarch is clearly newer than eigen3-devel-3.2.2-3.mga5.noarch, no conflicts should occur !?!?!

The same happened with lib64jsoncpp-devel claiming a conflict on the file:
/usr/include/jsoncpp/json

and also on one of my package, guvcview. A conflict appeared on a language file gview-v4l2core.mo appearing in there in the spec file:

%files -n %{libgvv4l2name} -f gview_v4l2core.lang


I set this bug as release blocker, just to attract attention in case something nasty is going on. Any idea how to fix this? At least for my package guvcview, I do not get it!

Thanks!

Cheers,
Chris.
Chris Denice 2017-03-11 11:18:32 CET

Priority: Normal => release_blocker

Rémi Verschelde 2017-03-11 11:26:30 CET

CC: sysadmin-bugs => (none)
Component: Release (media or process) => RPM Packages

Marja Van Waes 2017-03-11 13:15:44 CET

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

Comment 1 Marja Van Waes 2017-03-11 13:18:09 CET
(In reply to Chris Denice from comment #0)

> 
> The same happened with lib64jsoncpp-devel claiming a conflict on the file:
> /usr/include/jsoncpp/json
> 

CC'ing wally for that one, even if it should go into a separate report

CC: (none) => jani.valimaa

Comment 2 Jani Välimaa 2017-03-11 14:09:40 CET
Conflicts can happen if there's directory <-> symlink conversion.

From https://fedoraproject.org/wiki/Packaging:Directory_Replacement

"Due to a known limitation with RPM, it is not possible to replace a directory with any kind of file or symlink, nor is it possible to replace a symlink to a directory with a directory, without RPM producing file conflict errors while trying to install the package."
Comment 3 Jani Välimaa 2017-03-11 14:24:36 CET
(In reply to Jani Välimaa from comment #2)
> Conflicts can happen if there's directory <-> symlink conversion.
> 

And that's the case with eigen3 and jsoncpp. In both pkgs directory is changed to symlink.
Comment 4 Jani Välimaa 2017-03-11 15:31:06 CET
Fixed all mentioned pkgs:
* eigen3: added %pretrans script to remove old directory
* jsoncpp: added %pretrans script to remove old directory
* guvcview: splitted out translations from lib pkg (as lib major was changed, two different pkgs provided translation files with the exact same name -> conflict).
Comment 5 Chris Denice 2017-03-11 21:41:11 CET
Thanks Wally, you rock!!
Comment 6 Frédéric "LpSolit" Buclin 2017-03-12 17:55:05 CET
Can this bug be closed?
Comment 7 Marja Van Waes 2017-03-12 18:35:31 CET
(In reply to Frédéric Buclin from comment #6)
> Can this bug be closed?

I think so, wally pushed:

eigen3-3.3.3-2.mga6
jsoncpp-1.6.5-6.mga6
guvcview-2.0.5-3.mga6

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


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