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 copies.
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 environment.
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 http://freedesktop.org/wiki/Software/hal http://people.freedesktop.org/~david/talks/system-integration-and-gnome-guadec2006-davidz.pdf http://gitweb.freedesktop.org/?p=PolicyKit.git;a=summary 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+. cheers, Graeme Gill.