Hello,
I am the upstream maintainer of a number of colour management packages including icc-profiles-openicc and new to this list. Due to the speciality of matters, I jump in here.
Reason for my write: [colord] Add conflict on icc-profiles-openicc : https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131209/1...
Problem: The above Conflict tag breaks several packages, which rely on icc-profiles-openicc, namely oyranos and depending graphics software.
We have no bug reports upstream, or in openSUSE, where I maintain many colour management packages, nor see I such in Fedora in order to work upstream to fix anything. In the past I was able to fix several issues including those arrised by openSUSE, Fedora, Debian, Gentoo and other distro packagers.
The Conflict tag causes now uncertaincy to packagers and forces me to take from my development time on bug reports, finding out how packaging works in Fedora etc.
Request: remove the RPM spec Conflict tag immediately as it misuses the GNOME requirement for colord to block Oyranos from Fedora without fixable reasoning.
Bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1069672 (https://bugzilla.redhat.com/show_bug.cgi?id=1042655)
Background: colord author Richard Hughes sees himself as a competitor to the elder Oyranos project, which helped paving the way for linux color management. Not sure why he continues to repeat FUD[1] all over the place regarding Oyranos. See the open bug as an example for that. But, as you might imagine, that feels unfriendly.
kind regards and sorry for the noice Kai-Uwe
ku.b-mal wrote:
Hello,
I am the upstream maintainer of a number of colour management packages including icc-profiles-openicc and new to this list. Due to the speciality of matters, I jump in here.
Reason for my write: [colord] Add conflict on icc-profiles-openicc : https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20131209/1...
Problem: The above Conflict tag breaks several packages, which rely on icc-profiles-openicc, namely oyranos and depending graphics software.
I reverted the Conflicts pending some hopefully better solution forthcoming in: https://bugzilla.redhat.com/show_bug.cgi?id=1069672
On 28 February 2014 17:45, Rex Dieter rdieter@math.unl.edu wrote:
I reverted the Conflicts pending some hopefully better solution forthcoming in: https://bugzilla.redhat.com/show_bug.cgi?id=1069672
Well, I still stand by my logic; the user does not want two *different* sRGB system profiles on one system and it's confusing to have both in dialogs to choose from. The alternative is that I *hide* at runtime any duplicate system profiles in the daemon.
Background: colord author Richard Hughes sees himself as a competitor to the elder Oyranos project, which helped paving the way for linux color management.
I don't care so much for age, but I do care about adoption and users of the API:
http://qa.debian.org/popcon.php?package=colord http://qa.debian.org/popcon.php?package=oyranos
colord does take some of the specifications you developed for Oyranos and extends them significantly. I'm not sure how that's relevant here.
Not sure why he continues to repeat FUD[1] all over the place regarding Oyranos.
I think you probably need to link to actual things I've said rather than overarching statements. I'm trying to help build a cohesive operating system which doesn't allow swapping of core parts of the system. I'm happy to work with you on specifications but I'm not happy supporting an OS where one CMS is interchangeable with another when the design goals are so different.
Richard.
Am 28.02.2014 19:03, schrieb Richard Hughes:
On 28 February 2014 17:45, Rex Dieter rdieter@math.unl.edu wrote:
I reverted the Conflicts pending some hopefully better solution forthcoming in: https://bugzilla.redhat.com/show_bug.cgi?id=1069672
Well, I still stand by my logic; the user does not want two *different* sRGB system profiles on one system and it's confusing to have both in dialogs to choose from. The alternative is that I *hide* at runtime any duplicate system profiles in the daemon.
There are a number of situations your system could cover, in order to not fail by over simplifying. Two sRGB profiles in one system is maybe a user decission. Like a user installs original HP sRGB.icm profile, or that from Argyll or lcms or the official ICC web site.
You can easily *hide* any profile duplicates. I did so in the past in Oyranos, but later decided against it for the above reasoning. But that are design goals and that's entirely colord's and its users decission.
Given that colord is installed by default only for GNOME and otherwise colord or Oyranos is installed by user or distributor decission, there are few parallel installs likely.
Not sure why he continues to repeat FUD[1] all over the place regarding Oyranos.
I think you probably need to link to actual things I've said rather than overarching statements.
https://bugzilla.redhat.com/show_bug.cgi?id=1069672
I'm happy to work with you on specifications but I'm not happy supporting an OS where one CMS is interchangeable with another when the design goals are so different.
Irritating attitude for a free and open source software developer. Specs and software go hand in hand. Different concepts are needed to see what is inspiring or fits best. One example for that statement is your own desire to improve over existing software by starting a new project: colord.
Kai-Uwe
packaging@lists.fedoraproject.org
-
ku.b-mal -
Rex Dieter -
Richard Hughes