Bug 1042655

Below is what I see when I attempt to update colord and colord-libs, while removing icc-profiles-openicc.

Is this just a question of waiting for these packages to be updated? Other?

================================================================================
 Package                             Arch     Version         Repository   Size
================================================================================
Updating:
 colord                              x86_64   1.1.5-3.fc21    21koji      364 k
 colord-libs                         x86_64   1.1.5-3.fc21    21koji      155 k
Removing:
 icc-profiles-openicc                noarch   1.3.1-5.fc21    installed   1.7 M
Removing for dependencies:
 apache-commons-parent               noarch   32-2.fc20       installed    63 k
 apache-rat-plugin                   noarch   0.10-2.fc21     installed    58 k
 cobertura-maven-plugin              noarch   2.6-1.fc21      installed   138 k
 eclipse-birt-chart                  noarch   4.3.1-2.fc21    installed   6.7 M
 fop                                 noarch   1.1-5.fc21      installed   4.5 M
 httpcomponents-project              noarch   6-4.fc20        installed    32 k
 maven-checkstyle-plugin             noarch   2.10-2.fc20     installed   117 k
 maven-dependency-plugin             noarch   2.8-1.fc20      installed   225 k
 maven-doxia-module-fo               noarch   1.5-1.fc21      @21koji      73 k
 maven-doxia-sitetools               noarch   1.4-3.fc21      installed   185 k
 maven-doxia-tools                   noarch   1.4-13.fc21     installed    73 k
 maven-javadoc-plugin                noarch   2.9.1-2.fc20    installed   385 k
 maven-local                         noarch   3.4.2-1.fc21    @21koji     116 k
 maven-plugin-jxr                    noarch   2.4-1.fc21      @21koji      49 k
 maven-plugin-plugin                 noarch   3.1-16.fc21     installed    71 k
 maven-plugin-testing                noarch   2.1-9.fc20      installed    22 k
 maven-plugins-pom                   noarch   23-7.fc20       installed    20 k
 maven-pmd-plugin                    noarch   3.0.1-3.fc20    installed   168 k
 maven-project-info-reports-plugin   noarch   2.7-1.fc20      installed   296 k
 maven-reporting-impl                noarch   2.2-7.fc20      installed    63 k
 maven-site-plugin                   noarch   3.3-2.fc20      installed   212 k
 maven-surefire-report-plugin        noarch   2.16-1.fc20     installed    97 k

Transaction Summary
================================================================================
Upgrade  2 Packages
Remove   1 Package  (+22 Dependent packages)

(In reply to Michal Jaegermann from comment #0)
> A removal of icc-profiles-openicc is not an option as a numerous other
> packages depend on it.

Nothing should depend on icc-profiles-openicc -- the profiles are not very good and have not been updated in a long time. According to repoquery:

[hughsie@localhost hawkey]$ sudo repoquery --whatrequires icc-profiles-openicc
fop-0:1.1-5.fc20.noarch

For me, FOP is:

"""
FOP is the world's first print formatter driven by XSL formatting
objects. It is a Java application that reads a formatting object tree
and then turns it into a PDF document.
"""

I'll re-assign this to fop now to see if it actually needs the icc-profiles-openicc profiles, or if it just needs *any* sRGB profile. If it's not requiring a specific path or anything crazy like that, it would be safe to switch the dep to colord.

Perhaps also "providing" icc-profiles-openicc would be okay in colord.spec, although not strictly correct.

Richard

So, something like this works for me:

diff --git a/fop-Use-sRGB.icc-color-profile-from-icc-profiles-openicc.patch b/fop-Use-sRGB.icc-color-profile-from-icc-profiles-openicc.p
index aae3edb..a40018a 100644
--- a/fop-Use-sRGB.icc-color-profile-from-icc-profiles-openicc.patch
+++ b/fop-Use-sRGB.icc-color-profile-from-icc-profiles-openicc.patch
@@ -1,7 +1,7 @@
 From 275f22df6791135dde308f76cf4b2f7ec30f1840 Mon Sep 17 00:00:00 2001
 From: Michal Srb <msrb>
 Date: Fri, 12 Apr 2013 15:43:11 +0200
-Subject: [PATCH] Use sRGB.icc color profile from icc-profiles-openicc package
+Subject: [PATCH] Use sRGB.icc color profile from colord package
 
 It's a replacement for non-free color profile shipped with fop
 ---
@@ -30,7 +30,7 @@ index 60fea88..e041344 100644
 -        InputStream in = PDFDocument.class.getResourceAsStream("sRGB Color Space Profile.icm");
 +        InputStream in;
 +        try {
-+            in = new FileInputStream("/usr/share/color/icc/OpenICC/sRGB.icc");
++            in = new FileInputStream("/usr/share/color/icc/colord/sRGB.icc");
 +        } catch (FileNotFoundException e) {
 +            in = null;
 +        }
diff --git a/fop.spec b/fop.spec
index 2824b31..59b901e 100644
--- a/fop.spec
+++ b/fop.spec
@@ -27,7 +27,7 @@ Requires:     jakarta-commons-httpclient
 Requires:      apache-commons-io >= 1.2
 Requires:      apache-commons-logging >= 1.0.4
 Requires:      java
-Requires:      icc-profiles-openicc
+Requires:      colord
 
 BuildRequires: ant
 BuildRequires: java-devel

See https://bugzilla.redhat.com/show_bug.cgi?id=848659 for more info about the added dep.

* Thu Jan 2 2014 Richard Hughes <rhughes> 1.1-6
- Drop the icc-profiles-openicc requirement and switch to using the colord sRGB
  profile filename.
- Resolves: #1042655

(In reply to Richard Hughes from comment #2)
> 
> Nothing should depend on icc-profiles-openicc

I am really not in a position to discuss what should and should not depend on icc-profiles-openicc but I am only pointing out that various things do and closing your eyes to reality is not a very good approach.

Moreover with a forced conflict in a newer versions of colord you are making systems with icc-profiles-openicc installed non-upgradeable which does not look that exciting.  Would not be "Obsoletes:", which is missing, be rather in order?  Well, maybe in a fop spec?  "Providing" may work if other packages may indeed get by without  icc-profiles-openicc.  I have no idea.  "Provides" together with "conflict" looks somewhat contradictory.

> [hughsie@localhost hawkey]$ sudo repoquery --whatrequires
> icc-profiles-openicc
> fop-0:1.1-5.fc20.noarch

Running that check on an F20 installation I see something bit different:

# repoquery --whatrequires icc-profiles-openicc
fop-0:1.1-5.fc20.noarch
icc-profiles-basiccolor-printing2009-0:1.2.0-4.fc20.noarch
oyranos-0:0.4.0-12.fc20.x86_64

With all of this above, plus open questions from the end of comment #2, I am not so sure that closing that was not a bit premature.

(In reply to Michal Jaegermann from comment #5)
 
> Running that check on an F20 installation I see something bit different:

Hm, just repeated that on rawhide and got:

# repoquery --whatrequires icc-profiles-openicc
fop-0:1.1-5.fc21.noarch
icc-profiles-basiccolor-printing2009-0:1.2.0-4.fc20.noarch
oyranos-0:0.4.0-14.fc21.x86_64

so I am not sure how Richard in comment #2 got only fop.  As it happens on my rawhide installation I do NOT have neither oyranos nor icc-profiles-basiccolor-printing2009 packages present.

(In reply to Richard Hughes from comment #4)
> * Thu Jan 2 2014 Richard Hughes <rhughes> 1.1-6
> - Drop the icc-profiles-openicc requirement and switch to using the colord
> sRGB
>   profile filename.
> - Resolves: #1042655
> Fixed In Version: fop-1.1-6.fc21

Well, no, not really:

# rpm -q fop
fop-1.1-6.fc21.noarch
# yum update 'colord*'
.......
Resolving Dependencies
--> Running transaction check
---> Package colord.x86_64 0:1.1.4-1.fc21 will be updated
---> Package colord.x86_64 0:1.1.5-3.fc21 will be an update
---> Package colord-libs.x86_64 0:1.1.4-1.fc21 will be updated
---> Package colord-libs.x86_64 0:1.1.5-3.fc21 will be an update
--> Processing Conflict: colord-1.1.5-3.fc21.x86_64 conflicts icc-profiles-openicc
--> Finished Dependency Resolution
Error: colord conflicts with icc-profiles-openicc-1.3.1-5.fc21.noarch

Not that I am overly surprised.

looks like several bugs depend on this one:
904256
1069672

(In reply to Kai-Uwe Behrmann from comment #8)
> looks like several bugs depend on this one:
> 904256
> 1069672

proper links follow:
https://bugzilla.redhat.com/show_bug.cgi?id=904256
https://bugzilla.redhat.com/show_bug.cgi?id=1069672

The current rawhide version reverts the conflict in question.  Possibly a problem exists but not the one described in this report.