- No known issues except for amd64 in bug 283089. - Both amd64 and x86 will want also media-libs/jpeg-compat. - Bug 285586 needs to be done _first_ to avoid blurry images with gtk+ apps.
I hope this will get into 10.0 because it'd be shame to introduce this upgrade path to new users. Not something you want as your first experience.
the ebuild needs preserve lib logic added to it or it's going to break everything for stable users
(In reply to comment #2) > the ebuild needs preserve lib logic added to it or it's going to break > everything for stable users Mixing libjpeg.so.62 and libjpeg.so.7 will cause issues like bug 279227. I'd prefer getting "Can't find shared library..." message over random crashing, at least it'll be clear that the user needs revdep-rebuild.
Welcome to the world of the expat story. Those random crashes were also why I (with a couple other folks, including original expat maintainer) decided to not preserve_old_libs the previous ABI. That's the life without dist-upgrade :(
How about a news item...?
(In reply to comment #5) > How about a news item...? Yes, please...
except you already have this exact behavior with portage unstable and that is the behavior that is always going to exist moving forward. and it's going to happen anyways with packages that need to pull in jpeg-compat for binary packages. i.e. you cant win. people need to rebuild their systems with revdep-rebuild/@preserved-lib, end of story. the preserve lib logic needs to be added before going stable, or a temporary depend on jpeg-compat to prevent collision detection.
ive added the logic to jpeg-7 and the jpeg-compat ebuild http://sources.gentoo.org/media-libs/jpeg/jpeg-7.ebuild?r1=1.8&r2=1.9 http://sources.gentoo.org/media-libs/jpeg-compat/jpeg-compat-6b.ebuild?r1=1.1&r2=1.2
hrm, cvs out of date. actual change: http://sources.gentoo.org/media-libs/jpeg-compat/jpeg-compat-6b-r1.ebuild?r1=1.1&r2=1.2
ppc64 done
ppc stable
amd64 stable
Stable for HPPA.
Stable on alpha.
x86 stable
arm stable
ia64/m68k/s390/sh/sparc stable, closing