Description of problem: The latest rawhide update of colord apparently introduces conflicts with icc-profiles-openicc even when there are no file conflicts at all ... --------------------------------------------------- --> Running transaction check ---> Package colord.x86_64 0:1.1.6-2.fc21 will be installed --> Processing Conflict: colord-1.1.6-2.fc21.x86_64 conflicts icc-profiles-openicc --> Finished Dependency Resolution Error: colord conflicts with icc-profiles-openicc-1.3.1-5.fc21.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest --------------------------------------------------- I found the following note in the colord changelog: --------------------------------------------------- - Add conflict on icc-profiles-openicc - The OpenICC profiles are not really compatible for a few reasons: * The profiles are duplicates of the ones shipped in the colord package * The don't contain the correct metadata so the standard spaces show up in the device profile chooser. * The profiles don't contain an embedded ID, so colord has to hash them all manually at startup, which makes colord look bad in bootchart * A duplicate mime rule is installed which matches shared-mime-info one --------------------------------------------------- Unfortunately cinepaint depends on oyranos and oyranos depends on icc-profiles-openicc and as the colord is required by stuff like gnome-settings-daemon, it pretty much prevents cinepaint from being installed. Such conflicts need to be resolved by negotiation between you and the icc-profiles-openicc maintainer. Otherwise you break things. If you believe, that colord offers the same profiles like icc-profiles-openicc, then add the Obsoletes tag in the colord and create symlinks so that the colord package really acts as the icc-profiles-openicc replacement. I'm willing to modify cinepaint so that it searches for the profiles in the colord paths. Please, start the discussion here ... Version-Release number of selected component (if applicable): colord-1.1.6-2.fc21 icc-profiles-openicc-1.3.1-5.fc21
CCing Nicolas Chauvet who owns the icc-profiles-openicc package.
CCing Christopher Meng who owns the oyranos package.
CCing Kai-Uwe Behrmann and Michael Schwendt, as they might be of help here too. Feel free to remove yourself from CC if you're not interested in this topic.
Jaromir, thanks for CC'ing The cited colord ChangeLog is wrong or should at least be updated. * colord ships only virtual xml profiles, But contrarily Oyranos and other applications need on disk ICC profiles for various reasons. * icc-openicc-profiles have the mentioned profile ID since 1.2, and colord project is well aware of that * the meta data is not really specified in a collaborative manner, e.g. on OpenICC or XDG email list. They are still colord specific. One could go forward with that, to give that the necessary form in the ICC group. Perhaps the colord author? * The duplicate mime rule is in for completeness as the package predates the mime info in shared-mime package. On openSUSE the mime file is simply removed from the package. And I will fill a bug to the icc-profiles-openicc package to remove that in a future release. The actual github/colord/NEWS file does not mention above issues. Where does the above ChangeLog come from - link? Perhaps those issues are long ago gone and only forgotten to remove the conflict on the icc-profiles-openicc package?
Hello Kai-Uwe. The changelog message comes from the colord.spec (Rawhide/f21). * Wed Dec 11 2013 Richard Hughes <richard> 1.1.5-2
(In reply to Jaromír Cápík from comment #5) > The changelog message comes from the colord.spec (Rawhide/f21). > > * Wed Dec 11 2013 Richard Hughes <richard> 1.1.5-2 Thanks for the info, Jaromír. Then, that conflict is even more odd. Richard, can you please take back the recent colord conflict with icc-profiles-openicc. That conflict breaks other software, namely Oyranos, ICC Examin, KDE's KolorManager/KWin, CinePaint and perhaps some more. Please remember, I adapted the icc-profiles-openicc package during the 1.2 release to colord's needs to the extend possible. See this thread and the Next message from you: http://lists.freedesktop.org/archives/openicc/2011q2/004130.html On the technical side, colord does not require Oyranos and Oyranos not colord. So most users wont see any difference if the one or the other package and their profile packages are installed. If colord aims at being a essential GNOME desktop component, it can not conflict all ICC profile packages in Fedora and certainly not on Linux. So this approach does not scale at all for a main distribution like Fedora. If the conflict was indeed made because of the grouping of ICC profiles in GNOME-Color-Manager's profile selector, then that's on the technical side simply the wrong approach. Even though I agree that the UI problem is still there.
(In reply to Kai-Uwe Behrmann from comment #4) > Jaromir, thanks for CC'ing > > The cited colord ChangeLog is wrong or should at least be updated. > * colord ships only virtual xml profiles, But contrarily Oyranos and other > applications need on disk ICC profiles for various reasons. That's not really true. colord does have a .xml source representation of each profile, but builds them into binary .icc profiles it installs onto disk. > * icc-openicc-profiles have the mentioned profile ID since 1.2, and colord > project is well aware of that When I was testing they certainly didn't, but perhaps that's changed in the interim. I was under the impression that adding the profile-ids would change the MD5 sums which was important for various projects. > * the meta data is not really specified in a collaborative manner, e.g. on > OpenICC or XDG email list. They are still colord specific. One could go > forward with that, to give that the necessary form in the ICC group. Perhaps > the colord author? Most of the metadata is what what I've proposed before. The real crux of the issue is when both profile sets are installed weird things happen, like showing two *different* sets profiles with very similar names in applications. Richard
(In reply to Richard Hughes from comment #7) > (In reply to Kai-Uwe Behrmann from comment #4) > > Jaromir, thanks for CC'ing > > > > The cited colord ChangeLog is wrong or should at least be updated. > > * colord ships only virtual xml profiles, But contrarily Oyranos and other > > applications need on disk ICC profiles for various reasons. > > That's not really true. colord does have a .xml source representation of > each profile, but builds them into binary .icc profiles it installs onto > disk. colord profiles are tailored after Adobe, HP, Oyranos and other profiles and specs. Following your presented logic, they should conflict the colord ones as they predate? IMHO that makes not much sense for a main distro. > > * icc-openicc-profiles have the mentioned profile ID since 1.2, and colord > > project is well aware of that > > When I was testing they certainly didn't, but perhaps that's changed in the > interim. You changed that end of 2013, when the answer was already passed to you in may 2011. That is irritating. > I was under the impression that adding the profile-ids would change > the MD5 sums which was important for various projects. A MD5 sum of the whole profile is still *non* standard. See: http://lists.freedesktop.org/archives/openicc/2011q2/004132.html Further colord does not care about any standard ICC ID or non standard MD5 sums for its generated profiles, as that is currently not possible with the underlying lcms library. Each time the profiles are generated they have a differnt MD5 *and* ICC ID. > > * the meta data is not really specified in a collaborative manner, e.g. on > > OpenICC or XDG email list. They are still colord specific. One could go > > forward with that, to give that the necessary form in the ICC group. Perhaps > > the colord author? > > Most of the metadata is what what I've proposed before. The real crux of the > issue is when both profile sets are installed weird things happen, like > showing two *different* sets profiles with very similar names in > applications. Where are the bug reports?
Richard, I could not find a fit here: http://fedoraproject.org/wiki/Packaging:Conflicts Provide substantial input, which is needed to solve the situation. Or remove the Conflict tag from colord package immediately, as it unfriendly breaks other packages.
Hi Richard. I think Kai-Uwe is right at this point. According to the guidelines, adding unversioned Conflicts should be avoided at any cost. Even versioned Conflicts should be replaced with versioned Requires whenever it's possible. That would require a bug creation against icc-profiles-openicc and some negotiation between you two, so that both CMS systems could live in the Fedora world together. However, if you believe this is not the right way of doing things, for cases like this one an FPC ticket needs to be created and the case needs to be decided/resolved by the FPC crew: https://fedorahosted.org/fpc/newticket Please, select the way that suits your needs. Thanks in advance, Jaromir.
In the meantime... %changelog * Fri Feb 28 2014 Rex Dieter <rdieter> 1.1.6-3 - revert Conflicts: icc-profiles-openicc pending (hopefully) better solution (#1069672)
Well, looks like the decision has been taken for me. Closing this bug.
Hi Richard & Kai-Uwe. Please, talk to each other and try to find a way how to resolve the issues mentioned in your comments. If the situation really needs a better solution, then put down your weapons, re-open this bug and do it. Together if possible. Thanks for advance for not letting it go. Jaromir.