[argyllcms] Re: dispread fails with ubuntu packed argyllcms with i1pro
- From: Roland Mas <lolando@xxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 12 Jan 2010 16:59:32 +0100
Graeme Gill, 2010-01-10 08:58:00 +1100 :
[...]
> libusb has to be able to deal with two threads accessing the
> same device having independent timeouts. The original libusb V0.1
> code didn't handle that.
>
> [This is exactly why Argyll comes with its own copy of libusb, and why
> I strongly object to Linux distributions removing it - it's not a
> whim, there are very concrete reasons for not trusting whatever
> version of libusb happens to be on the system ! You certainly aren't
> doing yourselves or end users any favors distributing broken versions
> of Argyll, and I'm particularly unhappy about how it then reflects
> back on upstream.]
I understand your position, but it makes life much harder for
packagers, since it means several copies of libraries with slightly
different feature sets and bug sets are floating around on the system,
which means several times more time to spend on support, which nobody
wants to do. At least in the Debian project, the security team has this
policy of frowning deeply upon such a practice, and I doubt that libusb
could warrant an exception. Arguing with the security team to try to be
granted an exception is more time and energy than I'm willing to spend,
especially since I agree with the general policy. The Java-like mess is
not something I even want to hear about, let alone encourage.
Having said that, let me be more positive: the common way to achieve
consensus in these discussions is to get your libusb patches upstream.
Depend on a specific version of libusb if you doubt that future versions
will work, but once you don't need a fork you can concentrate on Argyll
and be rid of a whole class of bug reports (such as the one that started
this thread).
I also couldn't end this email here without mentioning that I feel a
bit awkward being asked simultaneously to stick to upstream and to
diverge from upstream. Sticking to upstream has my preference (also
yours, if I'm any judge), but then for consistency's sake I also stick
to libusb's upstream.
Graeme Gill, 2010-01-10 11:43:34 +1100 :
[...]
> [ But basically, who has time for all this ? Why is it so damn
> important to toss out known working code, and to link with unknown,
> untested code, when it is very well established that this area is
> rather fragile due to the vagaries of instrument and system USB
> drivers ? ]
One could ask who has time to maintain a forked version of a library
when submitting the occasional patch upstream would result in less work
for the forker and a fixed library for everyone.
> Since libusb 1.0 isn't API compatible with libusb-win32 1.0, I can't
> currently update the API Argyll uses. There is work on MSWindows
> support in libusb 1.0, but it's far from finished yet (it doesn't work
> with the MS compilers for instance, and the development hasn't been
> merged and widely tested yet). When and if this occurs, and/or I can
> find time to contribute to getting libusb 1.0 Win into shape, then
> I'll switch Argyll over to it (but much time will then be spent
> testing everything again). There may still be the issue with deployed
> systems libusb 1.0 compatibility though, so I will be inclined to
> continue to provide libusb with Argyll for some time.
Thanks for that information. I'm looking forward to the switch to
libusb 1.0, it sounds like it's going to make life easier for everyone.
Roland.
--
Roland Mas
Sauvez les castors, tuez les bûcherons.
Other related posts:
