Nicolas Mailhot wrote:
The Fedora libusb is there http://koji.fedoraproject.org/koji/packageinfo?packageID=782 You can open the src.rpm with tools like file-roller or 7zip to check what sources and patches we use.
I've checked this out as best I can against the Eye-One Pro, but couldn't reproduce the problem. It would take some more time to test it against all the other instruments though. It's unclear whether this is because my Linux distribution is quite old or not (One of the Fedora patches to libusb 0.1.12 is to do with Open Nat for instance, and this code isn't enabled on my system). So the problem reported by Ludovico Fischer is not easily resolved at present, and the simplest fix is to use the version of libusb that comes with Argyll.
This is how the game is played. There are pros and cons to each solution but every distribution decided long ago letting each app manage its copy of the libraries it needed was not an efficient resource use. It's a logic which has been validated on thousands of software packages over many years so there is little point going over it again now.
I think you'll find that I can choose how I want to play this game. If I think it best to ship my own libusb as a way of ensuring that Argyll works reliably, then it's not hard to it in such a way that it cannot be trivially switched to using some other version. [As far as I'm concerned this situation has analogies with the "taint" flags maintained in the Linux kernel. If you're running Argyll with a version of libusb I haven't qualified, then it's likely I'm not going to be in a position to trouble shoot it. My first piece of advice is likely to be "recompile using the version of libusb I've provided, and tell me if the problem still occurs".]
I'm afraid we have a bit of a culture clash. Argyll integration would be nowhere this painful if it had been managed like 90% of FLOSS projects instead of trying to follow one-of-a-kind rules.
It's my itch, and I'll choose how to scratch it. I think the freedom provided by open source software is being perverted if it is now the situation that distributions are attempting to dictate "how things shall be done" to independent projects. I'm perfectly happy to try and accommodate reasonable requests to make life easier in packaging Argyll, but that doesn't mean I'll necessarily do everything asked, particularly if I don't agree with the reasoning behind it.
BTW you should take a look as cmake, I hear it's good for producing Linux/OSX/Windows binaries as you need to and it's definitely more mainstream than jam.
I've been following it. My impression at present is that while cmake has a lot going for it compared to traditional build systems, boost.build is currently some way ahead in terms of ease of use and accommodating real world requirements. Graeme Gill.