/opt/icedtea6-bin-1.7.1/jre/lib/amd64/libsplashscreen.so is linked against libpng12.so where as SONAME is libpng14.so in >=media-libs/libpng-1.4 please rebuild icedtea6-bin against libpng 1.4 (or above)
I don't even see libpng in ~ yet, let alone being stable. If you really want a version of IcedTea linked against the new libpng, then emerge icedtea. It's now in the main tree. Binary ebuilds have to work for as great a subset of users as possible.
(In reply to comment #1) > I don't even see libpng in ~ yet, let alone being stable. If you really want a it's only matter of time, this bug was opened out of courtesy > version of IcedTea linked against the new libpng, then emerge icedtea. It's now > in the main tree. Binary ebuilds have to work for as great a subset of users > as possible. indeed, users would prefer to avoid installing old binary ABI slot of libpng (which is about to be created) if they can, and just see icedtea6-bin work with latest libpng in ~arch as it's in-house created binary-package. what will be: SLOT="0" or SLOT="1.4" of libpng (source based slot) SLOT="1.2" of libpng (only install SONAME, libpng12.so.0) and if icedtea6-bin isn't recompiled against libpng 1.4 to wait for the keywording now, users will see the old slot getting pulled in it's same what was done for media-libs/jpeg
IcedTea works with the new libpng. When the next binary is built, it will be built against whatever is stable. If that is libpng 1.4, then it will be linked against that. I don't handle the binary builds, but I'm sure it's not sensible to rebuild every time a dependent library is bumped (which includes most of X as well). If 'users would prefer to avoid installing old binary ABI slot', they can just emerge icedtea (the source variant). I think you're making a presumption about what users want and it may in reality only matter to a vocal minority.
(In reply to comment #3) > IcedTea works with the new libpng. When the next binary is built, it will be > built against whatever is stable. If that is libpng 1.4, then it will be > linked against that. Intresting. So you are making decisions for the gentoo-java team now? This wasn't how it was done for jpeg, so I'm assuming they will go the same route with libpng here. > emerge icedtea (the source variant). I think you're making a presumption about > what users want and it may in reality only matter to a vocal minority. ...
(In reply to comment #4) > (In reply to comment #3) > > IcedTea works with the new libpng. When the next binary is built, it will be > > built against whatever is stable. If that is libpng 1.4, then it will be > > linked against that. > > Intresting. So you are making decisions for the gentoo-java team now? This > wasn't how it was done for jpeg, so I'm assuming they will go the same route > with libpng here. > I think there's some misunderstanding between Andrew and Samuli here. The point is to provide binaries for libpng-1.4 users. That build doesn't need to go stable but icedtea6-bin isn't locked to cater to stable users only. That's why we have the keyword system. I think Caster knows how to handle this so thanks for the heads up.
+ 18 Mar 2010; Vlastimil Babka <caster@gentoo.org> + icedtea6-bin-1.7.1.ebuild: + Add a distfile with libsplashscreen.so built against libpng-1.4. The file + is selected depending on which libpng is installed. Fixes bug #308443.
It isn't even in unstable yet, never mind stable.
(In reply to comment #7) > It isn't even in unstable yet, never mind stable. Right, we usually try to fix reverse dependencies first before unmasking the package that breaks them, if possible.
Yeah I understand that. I see the ebuild is there now, just masked. I'd like to try it with IcedTea before we start rebuilding the binaries with it. Are you sure splashscreen is all that's affected? I'm dubious.
