virtual/jpeg-0 has >=media-libs/libjpeg-turbo-1.2.0:0. Since libjpeg-turbo-1.3.0-r2 that dependency is now wrong, because libjpeg-turbo-1.3.0 implements libjpeg.so.62 (see virtual/jpeg-62), but no longer builds a libjpeg.so.8. So any packages depending on virtual/jpeg:0 that expect libjpeg.so.8 will now be broken. Also if I try to switch to libjpeg-turbo (the suggested new default as per news item of 2012-04-24), then it wants to unmerge media-libs/jpeg-8d-r1 which it does not replace: # emerge -1av libjpeg-turbo These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/libjpeg-turbo-1.3.0-r3 USE="java -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB [uninstall ] media-libs/jpeg-6b-r12:62 ABI_X86="(64) (-32) (-x32)" [blocks b ] >=media-libs/libjpeg-turbo-1.3.0-r2:0 (">=media-libs/libjpeg-turbo-1.3.0-r2:0" is blocking media-libs/jpeg-6b-r12) [blocks b ] media-libs/jpeg:62 ("media-libs/jpeg:62" is blocking media-libs/libjpeg-turbo-1.3.0-r3) [uninstall ] media-libs/jpeg-8d-r1 USE="-static-libs" ABI_X86="(64) (-32) (-x32)" [blocks b ] media-libs/libjpeg-turbo:0 ("media-libs/libjpeg-turbo:0" is blocking media-libs/jpeg-8d-r1) [blocks b ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking media-libs/libjpeg-turbo-1.3.0-r3) Reproducible: Always Steps to Reproduce: 1.
(In reply to Ortwin Glueck from comment #0) > So any packages depending on virtual/jpeg:0 that expect libjpeg.so.8 will > now be broken. virtual/jpeg:0 was never meant to provide libjpeg.so.8, it's meant to provide the jpeg.so symlink and the package headers, so that's not a problem the known issues are already tracked at bug 499170, as in, the whole libjpeg.so.8 "issue" is limited to ~amd64 and emul-linux-x86- and the multilib package conversion, for which we don't need another bug for so i'll just close this... pointless report
