Hi Hans.
lcms2 was released on 8. May 2010 lcms v1 is on the way to be phased out in the newest distribution versions.
Are there any distributions that have released without v1?
I don't know, but Ubuntu has a bug for replacing lcms v1.
There is no reason, that Wine is the last app, which depends on lcms v1.
On Thu, 2013-05-09 at 18:56 +0200, wine.dev@web.de wrote:
Hi Hans.
lcms2 was released on 8. May 2010 lcms v1 is on the way to be phased out in the newest distribution versions.
Are there any distributions that have released without v1?
I don't know, but Ubuntu has a bug for replacing lcms v1.
There is no reason, that Wine is the last app, which depends on lcms v1.
For most apps it will be a matter of adding a configure check for lcms2 and then recompiling. This is not the case for Wine as you have pointed out.
At this point there's probably still a substantial number of users on distributions that don't include lcms2, and trying to support both doesn't make the source any prettier.
So it doesn't seem unreasonable to wait a little longer.
On 05/09/2013 01:37 PM, Hans Leidekker wrote:
On Thu, 2013-05-09 at 18:56 +0200, wine.dev@web.de wrote:
Hi Hans.
lcms2 was released on 8. May 2010 lcms v1 is on the way to be phased out in the newest distribution versions.
Are there any distributions that have released without v1?
I don't know, but Ubuntu has a bug for replacing lcms v1.
There is no reason, that Wine is the last app, which depends on lcms v1.
For most apps it will be a matter of adding a configure check for lcms2 and then recompiling. This is not the case for Wine as you have pointed out.
At this point there's probably still a substantial number of users on distributions that don't include lcms2, and trying to support both doesn't make the source any prettier.
So it doesn't seem unreasonable to wait a little longer.
On the Ubuntu side, all supported versions have liblcms2.
As far as source prettiness goes, it will be much easier to manage the transition as a distribution if we can know that Wine is ready rather than waiting on others to act (who in turn may be doing the same thing).
Thanks, Scott
Hi Hans.
For most apps it will be a matter of adding a configure check for lcms2 and then recompiling. This is not the case for Wine as you have pointed out.
- cmsCreateLabProfile was renamed to cmsCreateLab2Profile cmsvirt.c (1.19: 570) / (2.4: 458 and 497)
- cmsSetLogErrorHandler can be used as replacement for cmsSetErrorHandler
At this point there's probably still a substantial number of users on distributions that don't include lcms2, and trying to support both doesn't make the source any prettier.
The changes to support both versions are resonable small. Missing support for lcms2 in the next stable Wine release is bad.
So it doesn't seem unreasonable to wait a little longer.
gnome-settings-daemon / gnome-color-manager / openjdk and some other depend at least since Ubuntu 1110 on lcms2. (lcms2: 8 Packages, lcms1: 47 Packages)
In current distributions, the package list include libreoffice, gtk3, libraw, libkdcraw, poppler, ImageMagik, inkscape, scribus, calligra, cups-filters ... more than 50 packages. (That's for Ubuntu 1304 and Suse 1203)
I see no reason to wait any longer.
-- By by ... Detlef
On Fri, 2013-05-10 at 02:05 +0200, Detlef Riekenberg wrote:
For most apps it will be a matter of adding a configure check for lcms2 and then recompiling. This is not the case for Wine as you have pointed out.
cmsCreateLabProfile was renamed to cmsCreateLab2Profile cmsvirt.c (1.19: 570) / (2.4: 458 and 497)
cmsSetLogErrorHandler can be used as replacement for cmsSetErrorHandler
At this point there's probably still a substantial number of users on distributions that don't include lcms2, and trying to support both doesn't make the source any prettier.
The changes to support both versions are resonable small.
There's more. lcms1 carried the icc34.h header that defines the ICC format. It's included via lcms.h and we depend on it for functionality that the lcms1 API doesn't provide.
I have some hope that the lcms2 API will be sufficient for this functionality, otherwise we may have to carry this header ourselves.