2010/11/7 Pavol Rusnak :

On 07/11/10 13:53, Pavol Rusnak wrote:

...

On 04/11/10 19:46, Andrew Jorgensen wrote:

...

There are other good reasons to use libjpeg-turbo, namely the 2-4X speed (also battery) improvement.

I can prepare the package, push it to factory, obsolete and remove all existing ones, this is not a problem. Problem is we have to evaluate possible breakages, so I won't do it before I get GREEN from our openSUSE Release Team (coolo atm).

JFYI: I prepared the newest libjpeg-turbo package in home:prusnak repo. The spec is adapted from Fedora Rawhide, but I changed it accordingly to our shared library policy and added (hopefully correct) Obsoletes and Provides.

That "libjpeg62 obsoletes and provides libjpeg8" is probably wrong? Shouldn't it obsolete/provide libjpeg6? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2010/11/7 Pavol Rusnak :

On 07/11/10 15:40, Cristian Morales Vega wrote:

...

2010/11/7 Pavol Rusnak:

...

On 07/11/10 13:53, Pavol Rusnak wrote:

...

On 04/11/10 19:46, Andrew Jorgensen wrote:

...

There are other good reasons to use libjpeg-turbo, namely the 2-4X speed (also battery) improvement.

I can prepare the package, push it to factory, obsolete and remove all existing ones, this is not a problem. Problem is we have to evaluate possible breakages, so I won't do it before I get GREEN from our openSUSE Release Team (coolo atm).

JFYI: I prepared the newest libjpeg-turbo package in home:prusnak repo. The spec is adapted from Fedora Rawhide, but I changed it accordingly to our shared library policy and added (hopefully correct) Obsoletes and Provides.

That "libjpeg62 obsoletes and provides libjpeg8" is probably wrong? Shouldn't it obsolete/provide libjpeg6?

Right, we have libjpeg8 in 11.3, but we should also take care of older libjpeg6. Fixed.

I was trying to say that the libjpeg8 one should be removed. The new package does not have a library with soname "libjpeg.so.8", so doesn't "provide" what libjpeg8 provided. If someone happens to have installed a non-rpmed binary that links against libjpeg.so.8, when he updates to openSUSE 11.4 its libjpeg8 package will be removed (updated) and the binary will stop to work. Also, I just saw this: http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=236 Right now we need libjpeg-turbo for libjpeg v6 compatibility but also the original libjpeg for v8. But it seems the next version of libjpeg-turbo will be able to build libjpeg v6, v7 and v8 binary compatible libraries. So if that's what we want, we can get rid of the original libjpeg totally (supposing it's ready for 11.4). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

El 07/11/10 12:09, Cristian Morales Vega escribió:

...

...

That "libjpeg62 obsoletes and provides libjpeg8" is probably wrong? Shouldn't it obsolete/provide libjpeg6?

libjpeg-turbo has a different SONAME, so it SHOULD NOT not conflict, nor obsolete libjpeg8 in anyway. jpeg8 must remain installed on the user system on upgrade in case it is needed by other packages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2010/11/7 Pavol Rusnak :

On 07/11/10 16:40, Cristian Rodríguez wrote:

...

El 07/11/10 12:09, Cristian Morales Vega escribió:

...

...

...

That "libjpeg62 obsoletes and provides libjpeg8" is probably wrong? Shouldn't it obsolete/provide libjpeg6?

libjpeg-turbo has a different SONAME, so it SHOULD NOT not conflict, nor obsolete libjpeg8 in anyway.

jpeg8 must remain installed on the user system on upgrade in case it is needed by other packages.

Ah, I get it now. Fixed Obsoletes/Provides in my repo, please check if it's OK :-)

It's OK with me. So: - An update is/will be available for 11.3 for bnc#620175. Meaning libjpeg v6 uses versioned symbols. - A libjpeg-turbo package is available. Next upstream version will version symbols. Since they have a history of releasing a new version every two months I would not bother to patch 1.0.1. - libjpeg-turbo has a "Colorspace Extensions" that apps could rely on, and it seems there will be apps linked against libjpeg.so.6 for a long time and libjpeg-turbo is the only v6 still supported... I don't think anybody is going to argue about dropping libjpeg6 for 11.4 and use libjpeg62 (libjpeg-turbo) instead. What must be still decided is what to do with libjpeg.so.8, knowing that - It seems libjpeg-turbo will be libjpeg.so.6, by default, for a long time. - libjpeg-turbo supports the v8 "ABI", but with some features missing - libjpeg-turbo is a young project (registered in SF on 2010-02-05), but IJG neither has an history as an active project - libjpeg.so.6 is what LSB mandates and Fedora uses Ideally, I would - Compile against libjpeg62. Fedora and LSB perhaps are not great causes, but I can't think of even a bad cause to compile against libjpeg8 - Provide a libjpeg8-devel package from the http://www.ijg.org/ source. - Provide a libjpeg8 from IJG source and a libjpeg8-turbo*, conflicting between them. Since IJG will be version "8.x" and libjpeg-turbo version "1.x" I expect ZYpp to install the IJG version by default, that would ensure maximum compatibility. If a dev is using v8 IMHO he is accepting the reduced speed. But if an user wants the extra speed he could manually install libjpeg8-turbo. * Not possible until the next upstream release of libjpeg-turbo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org