It appears that media-libs/jpeg-8c, which was until 2 days ago the latest stable version on most arches in the tree, got inexplicably punted. Now the latest stable jpeg is 6b. 8d in in the tree, but is ~ for all arches. Moreover, this means there is currently *no* stable version which satisfies the virtual/jpeg dependency on jpeg:0. The ChangeLog entry explaining this removal says only "old", which is patently unhelpful, given that it was the current version. Arbitrary removal of current stable packages is not very nice to users, and in fact goes against documented Gentoo policy: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap8 "make sure you do not accidentally remove the newest/only stable ebuild for any architecture." Please re-add 8c to the tree, or stabilise 8d forthwith on all arches where 8c was stable.
I am almost certainly sure that there was a news message for your saying 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 --deselect media-libs/jpeg # emerge --oneshot media-libs/libjpeg-turbo media-libs/jpeg:0 will be left in tree as a fallback implementation.
(In reply to comment #1) > I am almost certainly sure that there was a news message for your saying > > 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 --deselect media-libs/jpeg > # emerge --oneshot media-libs/libjpeg-turbo > > media-libs/jpeg:0 will be left in tree as a fallback implementation. Except it *wasn't* left in the tree. The stable versions were punted!
Samuli could you please comment
*** This bug has been marked as a duplicate of bug 413281 ***
no point in stabilizing the fallback, but I can drop KEYWORDS to "" if that makes one happier. libjpeg-turbo is stable everywhere where everyone should move at. news item is out. *** This bug has been marked as a duplicate of bug 413281 ***
stop this nonsense. libjpeg is in the tree and will remain so including keywords. libjpeg-turbo as an alternative is irrelevant.
*cough*wow*cough* Stable for HPPA.
(In reply to comment #6) > stop this nonsense. libjpeg is in the tree and will remain so including > keywords. libjpeg-turbo as an alternative is irrelevant. there is no nonsense. it's the announced, official, continuation for the stable series of jpeg for gentoo. it's *not stable* not move from libjpeg-turbo to jpeg since it's forward compatible only in one direction, as packages are already using features from libjpeg-turbo which are not available in jpeg. KEYWORDS need to reflect this, either by leaving ~arch, dropped to "", but if you insist on pushing this to stable, I can always drop media-libs/jpeg:0 from the virtual/jpeg if this gets wrongly stabilized.
amd64 stable
(In reply to comment #8) what you describe will happen just the same for ~arch users as arch. if you want to have libjpeg-turbo be the default, that's fine. even add `ewarn` to the jpeg ebuild if you like. but "official gentoo" is a bit melodramatic. as for support, no one said you need to do it. i did it for years and can do it again. that doesn't mean it should be dropped from the virtual. the point of that is to allow control over the _baseline_. libjpeg-turbo provides additional symbols so anything using those should get flagged on the end user's box as missing. then it's a bug the user did themselves, not something the choices available forced.
Shouldn't those packages that rely on special features available only in media-libs/libjpeg-turbo rely explicitly on that package, while the vast majority of other packages that can utilize either one rely on the virtual? What's the point of a virtual package that only has one effective option?
fine, let's let people break their setups http://sources.gentoo.org/viewvc.cgi/gentoo-x86/virtual/jpeg/jpeg-0.ebuild?r1=1.8&r2=1.9 and ppc/ppc64/sparc/x86 stable
(In reply to comment #11) they optionally use the extended features. one could call it an automatic dependency. but adding a USE flag doesn't entirely make sense. it's a crappy situation either way.
the virtual's point was to provide migration path from media-libs/jpeg to media-libs/jpeg-turbo, and later, if media-libs/libjpeg-turbo gets unmaintained, provide an easy path back to media-libs/jpeg it was never meant to be used like this, but i'm not going to continue the arguing anymore. i can agree that we disagree what the virtual is supposed to do.
