For some time media-libs/libjpeg-turbo has been the default implementation of jpeg on ~x86. media-gfx/blender-2.49b-r2 respected this. upgrading from this gives: $ emerge -uvpDN world [ebuild NS ] media-gfx/blender-2.57-r1 [2.49b-r2] USE="dds elbeem game-engine iconv jpeg2k lcms openexr openmp sdl sse zlib -apidoc -collada -contrib -debug -ffmpeg -fftw -jack -openal -player -redcode -sndfile -tweak-mode -verse" LINGUAS="en -ar -bg -ca -cs -de -el -es -fi -fr -hr -it -ja -ko -nl -pl -pt_BR -ro -ru -sr -sv -uk -zh_CN" 16,413 kB [blocks B ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking media-libs/libjpeg-turbo-1.1.0) Total: 7 packages (2 upgrades, 4 new, 1 in new slot), Size of downloads: 30,154 kB Conflict: 1 block (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (media-libs/jpeg-8c, ebuild scheduled for merge) pulled in by media-libs/jpeg required by (media-gfx/blender-2.57-r1, ebuild scheduled for merge) (media-libs/libjpeg-turbo-1.1.0, installed) pulled in by media-libs/libjpeg-turbo:0 required by (virtual/jpeg-0, installed) Would this work if it used virtual/jpeg-0 instead of media-libs/jpeg Reproducible: Always
I said ~x86 - I meant ~amd64.
sping, it was just an accident, right? + 17 May 2011; Samuli Suominen <ssuominen@gentoo.org> blender-2.57.ebuild, + blender-2.57-r1.ebuild: + Use virtual/jpeg wrt #367779 by Ooblick.
(In reply to comment #2) > sping, it was just an accident, right? It's not my bug, I could only have caught it. Thanks for fixing.