Bug 402927 – media-libs/jpeg-8d version bump

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description teidakankan 2012-02-09 21:51:59 UTC]

968 Kb    Sun Jan 15 10:25:58 2012  Unix Tape Archive

http://www.ijg.org/files/jpegsrc.v8d.tar.gz

Reproducible: Always




Version 8d  15-Jan-2012
-----------------------

Add cjpeg -rgb option to create RGB JPEG files.
Using this switch suppresses the conversion from RGB
colorspace input to the default YCbCr JPEG colorspace.
This feature allows true lossless JPEG coding of RGB color images.
The recommended command for this purpose is currently
cjpeg -rgb -block 1 -arithmetic.
SmartScale capable decoder (introduced with IJG JPEG 8) required.
Thank to Michael Koch for the initial suggestion.

Add option to disable the region adjustment in the transupp crop code.
Thank to Jeffrey Friedl for the suggestion.

Thank to Richard Jones and Edd Dawson for various minor corrections.

Thank to Akim Demaille for configure.ac cleanup.

[Comment 1 Samuli Suominen (RETIRED) 2012-02-15 00:39:01 UTC]

In portage.    But you should really be on libjpeg-turbo thesedays as it's the default.

[Comment 2 Fab 2012-04-23 08:40:43 UTC]

(In reply to comment #1)
> In portage.    But you should really be on libjpeg-turbo thesedays as it's
> the default.


> 22 Apr 2012; Samuli Suominen <[e-mail]> -jpeg-8c-r1.ebuild,
>   -files/Makefile.in.extra:
>   old

May I ask why you are removing a version that is STABILIZED on many archs (bug #401109) ? And why in this case an emerge -uDN world does not downgrade media-libs/jpeg ? emerge is leaving an old and removed version of media-libs/jpeg on the system.

Third question : if libjpeg-turbo is now the default, why emerge does not propose me to migrate ?

[Comment 3 Samuli Suominen (RETIRED) 2012-04-23 10:39:04 UTC]

Yes, libjpeg-turbo is now default but it's fine to leave the system use 8c-r1 (or 8d). None of these have any known issues that would require immediate action.

With that said, I've just sent a small news item for review, that's basically just saying:

emerge -C jpeg:0
emerge -1 libjpeg-turbo

This is just an enchancement. Certainly nothing users should be getting worked up over, as in, you don't *have to do anything*.

[Comment 4 SpanKY 2012-04-23 15:44:47 UTC]

(In reply to comment #3)

the existence of libjpeg-turbo has no real bearing on keyword policy with jpeg.  like any other package, you can't go dropping stable keywords.

[Comment 5 Samuli Suominen (RETIRED) 2012-04-25 23:56:55 UTC]

(In reply to comment #4)
> (In reply to comment #3)
> 
> the existence of libjpeg-turbo has no real bearing on keyword policy with
> jpeg.  like any other package, you can't go dropping stable keywords.

of course it has, it's like moving eg. from ntfsprogs to ntfs3g (just picked recent example). 
the only exception here is that i've left the obsolete package in tree as a fallback.
the fallback doesn't get attention before it's needed.

so tree is in consistent state with best possible outcome.

[Comment 6 SpanKY 2012-04-26 00:59:40 UTC]

(In reply to comment #5)

those examples are nothing alike.  the ntfsprogs authors themselves have declared the project obsolete and all development has moved to ntfs3g.  libjpeg is not is not obsolete.

[Comment 7 Samuli Suominen (RETIRED) 2012-04-26 05:19:28 UTC]

(In reply to comment #6)
> (In reply to comment #5)
> 
> those examples are nothing alike.  the ntfsprogs authors themselves have
> declared the project obsolete and all development has moved to ntfs3g. 
> libjpeg is not is not obsolete.

it's not supported to move from system built with libjpeg-turbo, to jpeg, it's compatible only in one direction, and the best way to reflect this is with KEYWORDS. was hoping to leave it in ~arch only for this, but if it's forced stable, there is no other option than drop it from the virtual completely just like we have done for virtual/libffi. leave only one provider, and if the provider gets broken, it can get replaced by media-libs/jpeg again.