[argyllcms] Re: Argyllcms 1.0.1 packaged in fedora-devel
- From: "Hal V. Engel" <hvengel@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 27 Jul 2008 12:15:47 -0700
On Sunday 27 July 2008 11:25:32 am Frederic Crozat wrote:
> On Sun, Jul 27, 2008 at 8:11 PM, Hal V. Engel <hvengel@xxxxxxxxxxx> wrote:
> > I don't want to get into the middle of this. But the real issue here is
> > that there are problems with a commonly used library, libusb, that need
> > to be fixed. This is something that none of us has much control or
> > influence over. Graeme is doing what he believes is the right thing to do
> > to insure that ArgyllCMS works and I have followed the same path in some
> > of my own work so I can understand his point of view (I use a modified
> > version of lcms that has a mod that will not end up being available in
> > the stock version). Frederic is doing what he can to get the problem with
> > the library fixed at least in the context of the distro(s) he supports
> > and many of his points are valid. In some respects both are correct
> > although I think we can get more done if we work together rather than
> > snipping at each other. After all we want ArgyllCMS and the meter
> > libraries to work correctly with the stock library and anything we do
> > that does not move things in that direction is counter productive.
>
> Agreed. We have different objectives, but some are common, so, let's
> try to fix them.
>
> > Instead perhaps we can come up with a plan to get things fixed. One
> > approach would be to create a diffinitive patch or patch set for libusb
> > and make this available in a very visible place. Perhaps the patch
> > Frederic created is that patch? Once this is available all of us can open
> > bug reports with our various distro's asking them to apply that patch to
> > libusb. If even one major distro is using that patch (or patch set) then
> > most other distros should start picking up the patch without too much
> > effort on our part. Since this has already happened with fredora and
> > Mandriva then it is mostly a matter of getting other distros to start
> > using this patch. When most of the major distros are using this patch
> > perhaps at that point the libusb folks will see the light and create a
> > version that has been fixed. In the mean time most of us running Linux
> > platforms will be using distros that have a version of libusb that has
> > been fixed. Once that starts happening the Argyll build could prehaps
> > check to see if a patched version is installed and use the shared (but
> > patched) version rather than building with the built in version of
> > libusb.
> >
> > Frederic can you provide a link to the libusb patch(es)? Has anyone
> > verified that this patch does indeed fix the i1 pro issues in particular?
> > Graeme are there any other devices that will have problems if runing
> > agaist an unpatched libusb? I have tested the i1 display 2/Lt, Huey and
> > Spyder 2 with stock libusb and these are OK but I would be mroe than
> > ahppy to test these using this new set of patches. Frederic if you can
> > provide a link to the patch(es) I will open a bug report with my distro
> > (gentoo) and perhaps others here can do the same thing. This is the
> > correct approach to this issue. Users put pressure on the distros to get
> > it fixed and the distros put pressure on the library maintainers.
>
> Well, I don't want to take the credit of libusb patch : it is Graeme
> work, I "just" diffed unpatched libusb with the one shipped with
> Argyllcms 1.0.0, removed the windows and osX part (not relevant for a
> distro) and that is it. Patch is available from Mandriva SVN :
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/libusb/current/S
>OURCES/libusb-0.1.12-concurrency-timeout.patch?view=markup
You are correct that the patch just captures Graeme work. None the less you
took the time to create it, clean it up and put it some place where others
could access it. And that counts for something and is a nessary first step to
getting this problem fixed.
>
> This mean Mandriva Cooker libusb is exactly the same as the one
> version shipped in Argyllcms.
>
> I've seen discussion on libusb mailing-list about this patch, but it
> seems new maintainer of libusb is more interested in finishing the
> rewrite of libusb and don't want to loose time on maintaining the old
> code at the same time (we can't blame him for doing so).
>
> > I should also point out that although ArgyllCMS has not been packaged on
> > many distros LProf has been a standard package on many distros for a long
> > time and the next release of LProf will be using the ArgyllCMS meter
> > libraries. So even if your distro does not have an ArgyllCMS package you
> > can point to LProf as something that will need this in the near future.
> > That is this in not just about ArgyllCMS.
>
> Well, LProf is not really better either : no release for more than 2
> years and a forked version of Argyllcms inside (IIRC). So, it is no
> better than Argyllcms regarding shipping duplicate code ;)
Well there are several big differences. I have yet to see any distro have a
package that installs the ArgyllCMS meter and spline related code in a shared
library or set of libraries and the stock ArgyllCMS builds do not do this
either. Although this might be the case with the autotools build since the
autotools build for version 0.60 did install this code as shared libraries.
There are also issues with the API for the ArgyllCMS "libraries" which are
unstable and change at least to some extent with each new release. This
means that LProf needs to be modified which each new release of ArgyllCMS to
account for these API changes. So these are two issues that do not exist for
libusb that do exist for anyone who attempts to use the ArgyllCMS libraries.
Since it was not Graeme's intent to create shared libraries for anyone elses
use I have no right to complain about the above issues but it also means that
I need to figure out a way to deal with them. I would much rather that there
was a set of shared libraries with a stable API but that is not the current
situation and there is nothing I an do about it other than figure out how to
work my way around it.
In other words in one case (libusb) we are talking about a common shared
library that is likely installed on almost every linux machine on the face of
the planet and that has a stable API. In the other case we are talking about
libraries that are not intended for shared use and that are only installed on
perhaps a few thousand machines for which there is no standard installation
technique and which has an unstable API. These are totally different animals
and comparing them is not an Aplles to Apples comparison.
The more correct comparison is how LProf CVS has a modified version of lcms.
Since this is almost exactly the same situation as with ArgyllCMS and libusb.
Again it is a widely installed shared library with a stable API that is
missing a feature needed by a user (LProf). I would love to not have to use
a modified statically linked version of lcms but upstream will not fix the
issue that I have with it (they have flat out refused to fix it). Like
Graeme's situation with libusb I currently have no option other than to
include a staticaly linked modified version of lcms. And like the libusb
issue I have no way to fix the upstream side of this. If I provide you with a
patch can you make it part of your distro(s)?
Hal
Other related posts:
