[gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 88 bytes --]

I don't really think this is necessary, but some people seem to.

Looks fine?

- Samuli

[-- Attachment #2: 2012-04-23-libjpeg-turbo-by-default.en.txt --]
[-- Type: text/plain, Size: 754 bytes --]

Title: The default JPEG implementation is libjpeg-turbo
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*

libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
SIMD instructions to accelerate baseline JPEG compression/decompression by
about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
has numerous enhancements.

All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo

From here on out media-libs/jpeg:0 is only used as a fallback and at the time
of writing this news item, libjpeg-turbo has no known bugs that would require
using it.

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Ulrich Mueller]

>>>>> On Mon, 23 Apr 2012, Samuli Suominen wrote:

> I don't really think this is necessary, but some people seem to.
> Looks fine?

> Title: The default JPEG implementation is libjpeg-turbo

Too long. GLEP 42 allows a maximum of 44 characters only.

> Author: Samuli Suominen <ssuominen@gentoo.org>
> Content-Type: text/plain
> Posted: 2012-04-23
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: =media-libs/jpeg-8*

> libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
> SIMD instructions to accelerate baseline JPEG compression/decompression by
> about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
> has numerous enhancements.

I'd suggest to use our standard names for these architectures, i.e. x86,
amd64, and arm.

> All users are recommended to migrate:

> # emerge -C media-libs/jpeg:0
> # emerge -1 media-libs/libjpeg-turbo

> >From here on out media-libs/jpeg:0 is only used as a fallback and at the time
> of writing this news item, libjpeg-turbo has no known bugs that would require
> using it.

Maybe avoid the word "From" at the beginning of the line. eselect news
will escape it properly, but it looks somewhat ugly.

And please wrap the body text at 72 chars (GLEP 42 says so).

Ulrich

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On 04/23/2012 01:43 PM, Ulrich Mueller wrote:
>>>>>> On Mon, 23 Apr 2012, Samuli Suominen wrote:
>
>> I don't really think this is necessary, but some people seem to.
>> Looks fine?
>
>> Title: The default JPEG implementation is libjpeg-turbo
>
> Too long. GLEP 42 allows a maximum of 44 characters only.
>
>> Author: Samuli Suominen<ssuominen@gentoo.org>
>> Content-Type: text/plain
>> Posted: 2012-04-23
>> Revision: 1
>> News-Item-Format: 1.0
>> Display-If-Installed: =media-libs/jpeg-8*
>
>> libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
>> SIMD instructions to accelerate baseline JPEG compression/decompression by
>> about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
>> has numerous enhancements.
>
> I'd suggest to use our standard names for these architectures, i.e. x86,
> amd64, and arm.
>
>> All users are recommended to migrate:
>
>> # emerge -C media-libs/jpeg:0
>> # emerge -1 media-libs/libjpeg-turbo
>
>> > From here on out media-libs/jpeg:0 is only used as a fallback and at the time
>> of writing this news item, libjpeg-turbo has no known bugs that would require
>> using it.
>
> Maybe avoid the word "From" at the beginning of the line. eselect news
> will escape it properly, but it looks somewhat ugly.
>
> And please wrap the body text at 72 chars (GLEP 42 says so).

Thanks Ulrich. See attachment as draft #2.

[-- Attachment #2: 2012-04-23-libjpeg-turbo-by-default.en.txt --]
[-- Type: text/plain, Size: 756 bytes --]

Title: The default JPEG implementation
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*

libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2,
and NEON SIMD instructions to accelerate baseline JPEG
compression/decompression by about 2-4x on amd64, arm and x86
platforms. It is based on libjpeg/SIMD but has numerous enhancements.

All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo

media-libs/jpeg:0 will be left in tree as a fallback implementation
in case libjpeg-turbo will become unmaintained or suffers from issues
caused by, for example, upgrading the toolchain.

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

On 04/23/12 06:16, Samuli Suominen wrote:
> I don't really think this is necessary, but some people seem to.
> 
> Looks fine?
> 
> - Samuli

What is the plan for platforms that are not supported by libturbo?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Matt Turner]

On Mon, Apr 23, 2012 at 7:58 AM, Richard Yao <ryao@cs.stonybrook.edu> wrote:
> What is the plan for platforms that are not supported by libturbo?

It's not that they're not supported, just that libjpeg-turbo doesn't
have optimized routines for them. It'll still run fine. (Check the
keywords, you'll see that it's stabilized.)

[gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Duncan]

Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:

> Title: The default JPEG implementation

[...]

> All users are recommended to migrate:
> 
> # emerge -C media-libs/jpeg:0
> # emerge -1 media-libs/libjpeg-turbo

That of course leaves the system without a jpeg library between the jpeg 
unmerge and the completion of the libjpeg-turbo merge.  If the build 
process fails for some reason...

There's no way to use portage's automatic block-resolving ability here to 
avoid that, I take it?

I'd suggest warning people that some image processing apps might not work 
during the interim, and possibly suggest using qpkg to package up the old 
version for quick binpkg remerge, if the build goes bad.  And/or
ebuild /path/to/libjpeg-turbo-ebuild package up the new version first, so 
it's know to have at least built and binpkged correctly, before unmerging 
jpeg.

Since such instructions get a bit detailed for a news item overview, 
perhaps a link to a page explaining these sorts of details would be more 
appropriate than putting all that detail in the news item.
 
> media-libs/jpeg:0 will be left in tree as a fallback implementation in
> case libjpeg-turbo will become unmaintained or suffers from issues
> caused by, for example, upgrading the toolchain.

s/will become/becomes/

("Becomes" is more common usage and agrees better with "suffers" as well, 
which would otherwise need to be "will suffer" to match, but that's just 
a stilted construction all around, then.)

Also possibly: s/in tree/in the tree/
Alternatively: s/in tree/in-tree/

("The" is arguably needed here, unless it's made a single compound word, 
in-tree.  However, this isn't as odd sounding to me as the "in case ... 
will become" syntax and it may just be me being picky.  Another opinion 
might be helpful.)

Or better yet, the reasons the fallback might be needed don't really need 
to be enumerated at all.  What about simply omitting that, leaving only:

media-libs/jpeg:0 will be left in the tree as a fallback implementation.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Samuli Suominen]

On 04/23/2012 02:58 PM, Richard Yao wrote:
> On 04/23/12 06:16, Samuli Suominen wrote:
>> I don't really think this is necessary, but some people seem to.
>>
>> Looks fine?
>>
>> - Samuli
>
> What is the plan for platforms that are not supported by libturbo?
>

Matt's reply is accurate.

Re: profiles/updates/ 'move' lacks support for versioned syntax (was: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo)

[Samuli Suominen]

On 04/23/2012 03:28 PM, Duncan wrote:
> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>
>> Title: The default JPEG implementation
>
> [...]
>
>> All users are recommended to migrate:
>>
>> # emerge -C media-libs/jpeg:0
>> # emerge -1 media-libs/libjpeg-turbo
 >
> There's no way to use portage's automatic block-resolving ability here to
> avoid that, I take it?

Too bad profiles/updates/ doesn't support versioned syntax[1] like,

'move =media-libs/jpeg-8* media-libs/libjpeg-turbo'

Portage just says,

ERROR: Malformed update entry 'move =media-libs/jpeg-8* 
media-libs/libjpeg-turbo'

[1] http://bugs.gentoo.org/271985

Re: profiles/updates/ 'move' lacks support for versioned syntax (was: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo)

[Mike Gilbert]

On Mon, Apr 23, 2012 at 8:49 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 04/23/2012 03:28 PM, Duncan wrote:
>>
>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>>
>>> Title: The default JPEG implementation
>>
>>
>> [...]
>>
>>> All users are recommended to migrate:
>>>
>>> # emerge -C media-libs/jpeg:0
>>> # emerge -1 media-libs/libjpeg-turbo
>
>>
>>
>> There's no way to use portage's automatic block-resolving ability here to
>> avoid that, I take it?
>
>
> Too bad profiles/updates/ doesn't support versioned syntax[1] like,
>
> 'move =media-libs/jpeg-8* media-libs/libjpeg-turbo'
>

I don't think a package move is appropriate here anyway. That would
just move the files in vdb without actually building/installing
libjpeg-turbo.

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Mike Gilbert]

On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>
>> Title: The default JPEG implementation
>
> [...]
>
>> All users are recommended to migrate:
>>
>> # emerge -C media-libs/jpeg:0
>> # emerge -1 media-libs/libjpeg-turbo
>
> That of course leaves the system without a jpeg library between the jpeg
> unmerge and the completion of the libjpeg-turbo merge.  If the build
> process fails for some reason...
>
> There's no way to use portage's automatic block-resolving ability here to
> avoid that, I take it?
>

This works for me.

floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] media-libs/libjpeg-turbo-1.2.0-r1  USE="-java
-static-libs" 0 kB
[uninstall     ] media-libs/jpeg-8d  USE="-static-libs"
[blocks b      ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
media-libs/libjpeg-turbo-1.2.0-r1)

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
> On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> > Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
> >
> >> Title: The default JPEG implementation
> >
> > [...]
> >
> >> All users are recommended to migrate:
> >>
> >> # emerge -C media-libs/jpeg:0
> >> # emerge -1 media-libs/libjpeg-turbo
> >
> > That of course leaves the system without a jpeg library between the jpeg
> > unmerge and the completion of the libjpeg-turbo merge.  If the build
> > process fails for some reason...
> >
> > There's no way to use portage's automatic block-resolving ability here to
> > avoid that, I take it?
> >
> 
> This works for me.
> 
> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  N     ] media-libs/libjpeg-turbo-1.2.0-r1  USE="-java
> -static-libs" 0 kB
> [uninstall     ] media-libs/jpeg-8d  USE="-static-libs"
> [blocks b      ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
> media-libs/libjpeg-turbo-1.2.0-r1)
> 
> 

I guess it will work when jpeg is not in world file... maybe people
should be told to drop it and, then, let emerge do all the work
automatically.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Zac Medico]

On 04/23/2012 10:49 AM, Pacho Ramos wrote:
> El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
>> On Mon, Apr 23, 2012 at 8:28 AM, Duncan<1i5t5.duncan@cox.net>  wrote:
>>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>>>
>>>> Title: The default JPEG implementation
>>>
>>> [...]
>>>
>>>> All users are recommended to migrate:
>>>>
>>>> # emerge -C media-libs/jpeg:0
>>>> # emerge -1 media-libs/libjpeg-turbo
>>>
>>> That of course leaves the system without a jpeg library between the jpeg
>>> unmerge and the completion of the libjpeg-turbo merge.  If the build
>>> process fails for some reason...
>>>
>>> There's no way to use portage's automatic block-resolving ability here to
>>> avoid that, I take it?
>>>
>>
>> This works for me.
>>
>> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild  N     ] media-libs/libjpeg-turbo-1.2.0-r1  USE="-java
>> -static-libs" 0 kB
>> [uninstall     ] media-libs/jpeg-8d  USE="-static-libs"
>> [blocks b      ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
>> media-libs/libjpeg-turbo-1.2.0-r1)
>>
>>
>
> I guess it will work when jpeg is not in world file... maybe people
> should be told to drop it and, then, let emerge do all the work
> automatically.

This will do the trick:

   emerge --deselect media-libs/jpeg
   emerge --oneshot media-libs/libjpeg-turbo

-- 
Thanks,
Zac

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Sebastian Luther]

Am 23.04.2012 19:49, schrieb Pacho Ramos:
> El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
>> On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.duncan@cox.net>
>> wrote:
>>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as
>>> excerpted:
>>> 
>>>> Title: The default JPEG implementation
>>> 
>>> [...]
>>> 
>>>> All users are recommended to migrate:
>>>> 
>>>> # emerge -C media-libs/jpeg:0 # emerge -1
>>>> media-libs/libjpeg-turbo
>>> 
>>> That of course leaves the system without a jpeg library between
>>> the jpeg unmerge and the completion of the libjpeg-turbo merge.
>>> If the build process fails for some reason...
>>> 
>>> There's no way to use portage's automatic block-resolving
>>> ability here to avoid that, I take it?
>>> 
>> 
>> This works for me.
>> 
>> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
>> 
>> These are the packages that would be merged, in order:
>> 
>> Calculating dependencies... done! [ebuild  N     ]
>> media-libs/libjpeg-turbo-1.2.0-r1  USE="-java -static-libs" 0 kB 
>> [uninstall     ] media-libs/jpeg-8d  USE="-static-libs" [blocks b
>> ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking 
>> media-libs/libjpeg-turbo-1.2.0-r1)
>> 
>> 
> 
> I guess it will work when jpeg is not in world file... maybe
> people should be told to drop it and, then, let emerge do all the
> work automatically.

There is:

# emerge --deselect media-libs/jpeg

The problem is that this would also remove things like
media-libs/jpeg:62 from the world file.

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Zac Medico]

On 04/23/2012 11:03 AM, Sebastian Luther wrote:
> Am 23.04.2012 19:49, schrieb Pacho Ramos:
>> El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
>>> On Mon, Apr 23, 2012 at 8:28 AM, Duncan<1i5t5.duncan@cox.net>
>>> wrote:
>>>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as
>>>> excerpted:
>>>>
>>>>> Title: The default JPEG implementation
>>>>
>>>> [...]
>>>>
>>>>> All users are recommended to migrate:
>>>>>
>>>>> # emerge -C media-libs/jpeg:0 # emerge -1
>>>>> media-libs/libjpeg-turbo
>>>>
>>>> That of course leaves the system without a jpeg library between
>>>> the jpeg unmerge and the completion of the libjpeg-turbo merge.
>>>> If the build process fails for some reason...
>>>>
>>>> There's no way to use portage's automatic block-resolving
>>>> ability here to avoid that, I take it?
>>>>
>>>
>>> This works for me.
>>>
>>> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies... done! [ebuild  N     ]
>>> media-libs/libjpeg-turbo-1.2.0-r1  USE="-java -static-libs" 0 kB
>>> [uninstall     ] media-libs/jpeg-8d  USE="-static-libs" [blocks b
>>> ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
>>> media-libs/libjpeg-turbo-1.2.0-r1)
>>>
>>>
>>
>> I guess it will work when jpeg is not in world file... maybe
>> people should be told to drop it and, then, let emerge do all the
>> work automatically.
>
> There is:
>
> # emerge --deselect media-libs/jpeg
>
> The problem is that this would also remove things like
> media-libs/jpeg:62 from the world file.

If it removes media-libs/jpeg:62, then it will say so, and they can just 
add it back if that's what they really want. There's probably zero or a 
negligible number of people that would have media-libs/jpeg:62 and 
really want it there, so in practice we can pretend that they don't exist.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Walter Dnes]

On Mon, Apr 23, 2012 at 02:22:53PM +0300, Samuli Suominen wrote

> All users are recommended to migrate:
> 
> # emerge -C media-libs/jpeg:0
> # emerge -1 media-libs/libjpeg-turbo

  How about mentioning revdep-rebuild in the instructions?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Chí-Thanh Christopher Nguyễn]

Matt Turner schrieb:
> It's not that they're not supported, just that libjpeg-turbo doesn't
> have optimized routines for them. It'll still run fine. (Check the
> keywords, you'll see that it's stabilized.)

And on those platforms it will run equally fast or faster or slower?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 420 bytes --]

On Monday 23 April 2012 15:19:31 Walter Dnes wrote:
> On Mon, Apr 23, 2012 at 02:22:53PM +0300, Samuli Suominen wrote
> 
> > All users are recommended to migrate:
> > 
> > # emerge -C media-libs/jpeg:0
> > # emerge -1 media-libs/libjpeg-turbo
> 
>   How about mentioning revdep-rebuild in the instructions?

no need as they should be ABI forward compatible (if you consider turbo to be 
the superset)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Duncan]

Zac Medico posted on Mon, 23 Apr 2012 10:55:20 -0700 as excerpted:

> On 04/23/2012 10:49 AM, Pacho Ramos wrote:
>> El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
>>> On Mon, Apr 23, 2012 at 8:28 AM, Duncan<1i5t5.duncan@cox.net>  wrote:
>>>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as
>>>> excerpted:
>>>>
>>>>> All users are recommended to migrate:
>>>>>
>>>>> # emerge -C media-libs/jpeg:0
>>>>> # emerge -1 media-libs/libjpeg-turbo
>>>>
>>>> That of course [temporarily] leaves the system without a jpeg
>>>> library[.]  There's no way to use portage's automatic
>>>> block-resolving ability[?]

> This will do the trick:
> 
>    emerge --deselect media-libs/jpeg
>    emerge --oneshot media-libs/libjpeg-turbo

That's exactly the sort of solution I was hoping for.  Thanks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Samuli Suominen]

On 04/23/2012 08:55 PM, Zac Medico wrote:
> On 04/23/2012 10:49 AM, Pacho Ramos wrote:
>> El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
>>> On Mon, Apr 23, 2012 at 8:28 AM, Duncan<1i5t5.duncan@cox.net> wrote:
>>>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>>>>
>>>>> Title: The default JPEG implementation
>>>>
>>>> [...]
>>>>
>>>>> All users are recommended to migrate:
>>>>>
>>>>> # emerge -C media-libs/jpeg:0
>>>>> # emerge -1 media-libs/libjpeg-turbo
>>>>
>>>> That of course leaves the system without a jpeg library between the
>>>> jpeg
>>>> unmerge and the completion of the libjpeg-turbo merge. If the build
>>>> process fails for some reason...
>>>>
>>>> There's no way to use portage's automatic block-resolving ability
>>>> here to
>>>> avoid that, I take it?
>>>>
>>>
>>> This works for me.
>>>
>>> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies... done!
>>> [ebuild N ] media-libs/libjpeg-turbo-1.2.0-r1 USE="-java
>>> -static-libs" 0 kB
>>> [uninstall ] media-libs/jpeg-8d USE="-static-libs"
>>> [blocks b ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
>>> media-libs/libjpeg-turbo-1.2.0-r1)
>>>
>>>
>>
>> I guess it will work when jpeg is not in world file... maybe people
>> should be told to drop it and, then, let emerge do all the work
>> automatically.
>
> This will do the trick:
>
> emerge --deselect media-libs/jpeg
> emerge --oneshot media-libs/libjpeg-turbo
>

Thank you. News item committed and used your (above) advise.

Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo

[Samuli Suominen]

On 04/23/2012 10:40 PM, Chí-Thanh Christopher Nguyễn wrote:
> Matt Turner schrieb:
>> It's not that they're not supported, just that libjpeg-turbo doesn't
>> have optimized routines for them. It'll still run fine. (Check the
>> keywords, you'll see that it's stabilized.)
>
> And on those platforms it will run equally fast or faster or slower?
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>

based on what i've seen on mailinglists wrt libjpeg-turbo upstream:

mostly equally, but due to later non-assembly improvements in IJG's 
jpeg, in some cases, a bit slower at least in 1.2.0 release of libjpeg-turbo
but nothing anyone should be worried over about, as those changes are 
reviewed and/or in process of being reviewed and backported on as needed 
basis


(almost left this message unsent because i'm totally lazy to dig up the 
references for above, sorry)

- Samuli