Seems like my previous post didn’t make enough of a fuss to get other developers to work on feasible solutions to avoid the problem to hit stable users… and now we’re back to square one for stable users.
Since I also stumbled across two problems today while updating my stable chroots and containers, that represent the local install of remote vservers, and a couple of testing environments for my work, I guess it’s worth writing of a couple of tricks you might want to know before proceeding.
Supposedly, you should be able to properly complete the update without running the libpng-1.4.x-update.sh hack! (and this is important because that hack will create a number of problems on the longer run, so please try to avoid it!). If you have been using --as-needed for a decent amount of time, the update should come almost painless. Almost.
I maintained that revdep-rebuild should be enough to take care of the update for you, but it comes with a few tricks here that make it slightly more complex. First of all, the libpng-1.4 package will try to “preserve” the old library by copying it inside itself, avoiding dynamic link breakage. This supposedly makes for a better user experience as you won’t hit packages that fail to start up for missing libraries, but has two effects; one is that you may be running a program with both libpng objects around, which is not safe; the second is that revdep-rebuild will not pick up the broken binaries at all, this way.
Additionally, there is a slot of the package that will bring in only the library itself, so that binary-only packages linked to the old libpng can be used still; if you have packages such as Opera installed, you might have this package brought in on your system; this will further complicate matters because it will then collide with libpng-1.4… bad thing.
These are my suggested instructions:
- get a console login, make sure that GNOME, KDE, any other graphical interface is not running; this is particularly important because you might otherwise experience applications that crash mid-runtime;
emerge -C =libpng-1.2*make sure that you don’t have the old library around; this works for both the old complete package and for the new library-only binary compatibility package;rm -f /usr/lib/libpng12.so*(replacelib/withlib64/on x86-64 hosts; this way you won’t have the old libraries around at all; actually this should be a no-op since you removed it, but this way you ensure you don’t have them around if you had already updated;emerge -1 =libpng-1.4*installs libpng-1.4 without preserving the libraries above; if you had already updated, please do this anyway, this way you’ll make sure it registers the lack of the preserved libraries;revdep-rebuild -- --keep-goingit shouldn’t stop anywhere now, but since it might, it’s still a good idea to let it build as much as it can.
Make also sure you follow my suggestion of running lafilefixer incrementally after every merge, that way you won’t risk too much breakage when the .la files gets dropped (which I hope we’ll start doing systematically soon), by adding this snipped to your /etc/portage/bashrc:
post_src_install() {
lafilefixer "${D}"
}
Important, if you’re using binary packages! Make sure to re-build =libpng-1.4* after you deleted the file, if you had updated it before; otherwise the package will have preserved the files, and will pack it up in the tbz2 file, reinstalling it every time you merged the binary.
This post brought to you by the guy who has been working the past four years to make sure that this problem is reduced to manageable size, and that has been attacked, defamed, insulted and so on so forth for expecting other developers to spend more time testing their packages. If you find this useful, you might want to consider thanking him somehow…
«If you find this useful, you might want to consider thanking him somehow»Already done :)And not regretting it one bit.(also, rofl at the whole last paragraph)
Ya, I just went through the hell of this and that is basically what I did.I cycled through this till revdep-rebuild was happylafilefixer “${D}”revdep-rebuild — –keep-going
Hi Diego!I’m in the middle of updating an older laptop right now. I’ve been following advice here: http://forums.gentoo.org/vi…Specifically, I had decided on:at a CLI:emerge –syncemerge -1 libpnglafilefixer –justfixitemerge -1 cairo pango libglade GTK+lafilefixer –justfixitrevdep-rebuildemerge -uND @worldrevdep-rebuildI do have Opera installed. Is the above sufficient? Should I change any steps? Are there steps I should add?At the moment, I’m at step:emerge -uND @world and will be for quite awhile. It’s not the world’s fastest laptop being only a Pentium III mobile at 1.1GHZ with 512 MB RAM.What I’m really wondering if I need to follow the removal of lpng12 step(s) you indicate and where I should do so.Thanks again for all that you do. I really do appreciate it even though I don’t always understand it.
The advice I’m currently following was posted in page two of the above thread. I believe it starts at post 6277134. 😀
@dufeu: the method you found is overly complicated by the very same problem I described above. And the reason why prometheanfire also went to cycle through it…My method was definitely faster and cleaner… as a single run _will_ work properly, if my steps are taken.
Thanks @Flameeyes.I had already started the upgrade. Had a total of 342 packages {includes kde-4.4.4} so the extra packages and steps are not the largest part of the time needed. i.e. revdep-rebuild did 37 packages {over and beyond the 342 needed for the upgrade}.Unfortunately, I started {running on and off} 3 days ago … :DThe upgrade step seems to be running pretty well at the moment. There are 281 packages still to go. Most of the non kde packages have completed.
Sorry, don’t really like this post so much. It seems one (other) dev worked QUITE hard to get libpng stable quickly, including all of the other packages necessary to do so. Instead of calling the script a hack (though I believe it isn’t ideal either), or trying to take more credit for yourself (and asking for donations as a result?), a how-to + perhaps notice of the devs work would fit better here.I usually read and enjoy your posts quite a bit (especially learning of autotools and linking issues; –as-needed made my upgrade quite smooth 🙂 ), but this one just felt out of place to me.
Andrew, as much as I’m sure Samuli is doing his best here, the libpng update didn’t fell to be handled properly neither for ~arch bump, nor here. Bumping this for *a security issue* is a bad choice, full stop. The script is a hack, and I don’t think Samuli would disagree on that. The whole thing should have been handled better in respect of many issues.Problem is that Gentoo developers on the whole seem to prefer reacting rather than planning. Again after the shit hit the fan, the rest of the developers woke up as @–as-needed@ needs to get the default. Did they wake up to the need of fixing the @.la@ files mess yet? Don’t think so.Did you miss the one developer who even told me I should move to Fedora because I think we should be using @–as-needed@ as they do?Did you miss the fact that my tinderbox is using up my own home power to grind the whole tree to find the issues? Kudos to Samuli and Kacper for handling the patching step now, but I don’t think it’s uncalled for me to note that *I’ve been saying this was needed since 2006*.I’m sorry this might sound off to you, but Samuli has been _way_ too trigger-happy regarding the whole libpng 1.4 thing; sure there weren’t _many_ bugs still standing when he first closed the tracker, but there were a couple; and sure, most of the systems will be fine after some screwing up for this but it requires a huge amount of work for a _security issue_, that would have been better solved by keeping the 1.2 around.I actually blame more the party of “Gentoo is dying because it’s no longer bleeding edge and bugged” rather than Samuli on this; we’ve been waiting for libpng-1.4 definitely too much, but this change was too fast. About a month for stable a package is fine when it’s not something that requires a re-merge of half a desktop system with our default settings.
I’m just resigned to using “emerge -e world” to fix issues like this when they arise. I tried to follow your five steps above but I’ve got some a “multiple packages pulled in the same slot problem” with gtk+ when I get to the revdep-rebuild step so it’s easier to just rebuild the whole damn system than screw around with it any more.
@jack that should only happen if you have some libpng version masked locally (@/etc/portage@). If that’s not the case, it definitely interests me… can you send me your world file?
Thanks for all your good work on Gentoo. Had a look at your Amazon list, DT’s Train of Thought is a great album. Hope you get it soon.
I appreciate your work very much. Without you Gentoo would not be what it is (especially in terms of stability).
Hi, two days ago I used the libpng-1.4.x-update.sh script and got no problems, yesterday I decided to also follow your instructions and got no problems either, today I synced and here’s what I get:These are the packages that would be merged, in order:Calculating dependencies… done![ebuild NS ] media-libs/libpng-1.2.44 [1.4.3] 0 kBI thought I had just gotten rid of it and now it’s getting back in a slot! Do I really need this?thanks for your insight and hard work
@demaledetti it’s correct if you have binary packages; once you follow the instructions I wrote down, it’s safe to install the binary-compatibility slot.
Hi, PNG upstream guy here.This is a heads-up that libpng-1.5.0 will be outbefore long. It will require application authors tobite the bullet and remove deprecated code,in particular anything that makes direct access tothe members of png_ptr or info_ptr. See thelatest libpng-1.5.0betaNN.On most platforms, libpng10, libpng12, libpng14,and libpng15 are able to coexist. We maintainthe older ones for applications that haven’t beenat least relinked against the current one if notrecompiled with the current png.h.Searching google groups for “libpng”, it seems that gentoo does something differently that makes it moredifficult for them to coexist. I don’t know if thereis anything we can do upstream about that.Glenn
Hi Glenn,I guess the problems here happen because we have a @libpng.so@ compatibility symlink for the applications that use @-lpng@ and the same goes for @libpng.pc@ … and the headers.If we were all to support @pkg-config@ only, and have proper fallbacks “as described here”:https://autotools.info/pkgcon… then it would be trivial, but too many packages will fail with that.
Thanks for your work Flameeyes !I’ve been using lafilefixer in post_src_install for some times (and I’ve rebuild my @world with it) and it seems to do its job without any issue. On b.g.o, there are some open bugs, but nothing harmful.I think it could be great to make it mandatory for the PM. I saw bug #271129, but there’s not much activity …And I wasn’t able to find if there’s any effort to remove .la files when it’s possible. Such thing would be great.
Hi Flameyes, thanks for all your efforts on this.What is the score on as-needed ?I have just spent three days doing emerge -e world WITHOUT that after seeing post by Spanky saying it was a bad, a waste of time and unneeded since it was enabled in ebuilds where it worked.At the end of world, I have a broken opera.I dropped to console , checked 1.2 is no longer there removed 1.4 and rebuilt it.Still I have a broken opera.I don’t understand how Opera can work if 1.2 is missing.What do I need to do to get this fixed.TIA.
btw I also ran fixlafiles –justfixit at each step
I blame Gentoo for being 3 years behind all other major distributions as we don’t have -Wl,–as-needed by default yet.Full stop.
Futhermore the update script’s job was never to be anything else than immediate hotfix for the building issues. It’s not trying to be smart in anyway:You have bunch of .la files in your system, referencing -lpng12. They existed before.Then the script will simply rename them to -lpng14.I refuse to even try to make it smart, the underlying problem is the lack of asneeded default in Gentoo and the problem that we install unnecessary .la files with gtk+, cairo, pango and others. and btw, I don’t maintain those packages.
And I don’t like the preserved-libs behavior at all either. But… It’s the best we can do because Portage 2.2 is still not stable, or even in ~arch for proper @preserved-libs feature.Also Portage is missing the feature that would allow maintainers to list package to be rebuilt if another package was updated. Only way we currently have this is dummy-revision bumps, with no ebuild changes and it still doesn’t work since there’s no way to force Portage to emerge packages in right order.
Ok, so I followd Flameeyes’ recommendation for a clean future compatible system then added back in 1.2 in a slot to get opera back.emerge libpng:1.2That seems to be about the best overall solution.Thx F/eyes.
I updated world and it stopped halfway through at gst-plugins-pango having already updated libpng. I hadn’t seen this post, so I followed the elog instructions and ran /usr/sbin/libpng-1.4.x-update.shThat didn’t actually fix the problem though, so I’ll try these steps here.It’s gets tiresome to have to read through blog posts and bugzilla comments just to work out how to update a stable Gentoo system…Thanks for all your hard work and informative blog posts.
I ignored your guide on my first machine to upgrade, and paid for it in wasted time (only remembering your guide half way through).On my second machine, the Diego-approved update went nice and smoothly. I expect that my third will be just as smooth.Thank you! 😀
Just wanted to say a quick thank you for this blog post! My portage-fu is a little rusty after taking a sebatical from Gentoo for a year, so these instructions saved me a massive headache.Quite annoying that I’ve had to rebuild practically my entire system though. This screw-up really was avoidable. And I’m sure I’m not the only one to have to do this, either. 🙁
Just wanted to say a quick thank you for this blog post! My portage-fu is a little rusty after taking a sebatical from Gentoo for a year, so these instructions saved me a massive headache.Quite annoying that I’ve had to rebuild practically my entire system though. This screw-up really was avoidable. And I’m sure I’m not the only one to have to do this, either. 🙁
one big thank you for this post.finally considered going with new libpng, but such a pain. with your post, it’s “just” 130 ports to go for an up-to-date desktop.thanks (-:
Just a note:If you are running x86_64 and/or amd64 architecture, be careful about having orphans left in /usr/lib32/. Was following the instructions on this post, and kept getting a failure rebuilding/updating Gnome as one of the packages, (gnome-desktop-base, iirc) kept looking for libpng12. I had already removed the libpng-1.2 package from my system and I kept trying to figure out where it was getting it from. I did a ‘find /usr/lib* -iname “libpng*” -print’ and found 3 entries in /usr/lib32.HTH.Regards,ShadowCat8
Hi,i run into a serious conflict with libpng update.I can’t get compile these packages:pango, gtk+, gimp, popplerI send a bugreport about the poppler (i don’t know about libpng at this time) issue:http://bugs.gentoo.org/show…The emerge fails when a shell script collect the .la files.I’ve tried these already:a, emerge -eav systemb, revdep-rebuild — –keep-goingc, lafilefixer –justfixit and /usr/sbin/libpng-1.4.x-update.sh (before every revdep)thanks,zemei