[argyllcms] Re: Argyll CMS in Fedora (and Mandriva)

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 14 Dec 2007 23:35:24 +1100

Nicolas Mailhot wrote:
Unfortunately that's not the case from a packaging point of view. That's
been my experience and that of all the other people I know who tried to
package argyll. Why do you think that despite being there for a decade,
and pointed to in every CMS howto in the web, Argyll had not been included in any distribution till very recently?

Inflexibility on the part of the distributions ? :-)

But it's not my particular goal to have Argyll in every distribution -
if people find it of sufficient value, they will take the trouble
to use it, if they don't value it, they wont. The source code arrangements
are primarily for my convenience rather than anyone else's, since I'm
the one that has to deal with it day in day out, but neither
am I deliberately trying to make it difficult for others either.

And the binary packagings are there for casual users.

jam may be modular internally but it assumes a static environment which
makes it very hard to get it to use system libraries instead of internal

It's not the modularity of the build system itself that concerns me,
it is the modularity of the build scripts. And I'm not sure I
understand what you mean about assuming a static environment -
being a proper language, it can be made quite responsive to its

Are you saying the usb_detach_kernel_driver_np() doesn't work
correctly on all systems, or is there some other issue ?

It's a workaround. We hate workarounds Fedora-side. Things should "just
work" without bandaids. Just blacklist the thing upstream.

Well it does "just work" from my perspective (at least on my test system).
The HID driver grabs the Huey (as it should, it's labelled an HID device),
and an application that want's to use the device another way (Argyll), is able
to tell the HID driver to let it go. It's much better at least than OS X
where you have to install a codeless kernel extension to achieve the same
result, or having to compile an exception into a driver !

fdi files are hal files and the exact hal layer that manages permissions
is PolicyKit


Unfortunately documentation is somewhat the weak point of those efforts.

Thanks, I'll try and familiarize myself with it.

Anything which is able to detect system libraries and their build flags
through pkg-config will do fine. It seems to me Jam is lightweight at
the expense of every facility packagers expect in modern software.

OK, I'll see if I can incorporate some automatic detection of the
system libraries when/if I convert to bjam.

A switch that makes argyll use dynamic linking internally would help
too. Separate dynamic libraries make license auditing easier (BTW you
haven't answered whether the GPVv2 files listed in the doc are also
GPLv3 licenced or not. If not you have a licensing conflict)

Sorry, I started to compose a reply to your initial posting, but
haven't finished it.

There are (as far as I know), only two files that I felt weren't clearly
LGPL or GPLv2+, and that's spectro/filmread.c and target/filmtarg.c (the
latter which I have mistakenly changed the license of I notice in the last
Beta release), which is why I made a special case out of them. If it causes
you issues, the simplest thing is to omit them, as they aren't widely used,
and in any case printread largely supersedes filmreads functionality. If as
you indicate there is a licensing conflict, I'll also remove them from my
next release, or at least enquire as to whether it's possible to change their
license to be GPLv2+.


Graeme Gill.

Other related posts: