Duncan wrote: > > Yes indeed. Fortunately for the bug I mentioned above, I hadn't cleared > out the binpkgs for 4.6.0 and 4.6.1, so it was easy enough to use them. > > Just in case you weren't aware, the binpkg format is simply a tarball of > the files as they'd install (from the fake-install immediately prior to > what would be the qmerge step if FEATURES=-binpkg), with some extra data > glued on the end. It's possible to open and browse the tarball content > using most archivers, including both ark and mc's virtual tarball > filesystem. > > Additionally, if you edit the file itself, near the end you'll find the > actual ebuild used, as plain text. Of course you can also use qxpak from > the portage-utils package to unpack the entire thing, but I usually simply > grab the plain text ebuild with a simple text editor, if that's all I > need. (It usually is, short term anyway. Longer term, the in-tree/in- > overlay eclasses might change in an incompatible way since they don't have > to worry about compatibility with the removed ebuild any longer, thus > making use of the ebuild-only difficult without the environmental data > contained in the rest of the xpak.) > > So using something like mc, which can diff between comparable files in two > different tarballs directly, no manual extracting required (I think it > does that to a temp area on its own but it's all automatic if so, and it > may handle it entirely in memory for small files), it's quite possible > indeed to see what has changed, either in filesystem layout and filenames, > or between two config files, say, while working with just the binpkgs > without even extracting them let alone installing them. > > And if you need the ebuild, grabbing it from the binpkg is easy enough as > well, tho as I said, if they've changed the eclasses it depends on in the > mean time, you may have a bit more work to worry about than just the > ebuild, but they too can be recovered from the xpak if necessary, thus > giving one the necessary bits to do a from-source rebuild as well as > simply using the existing binpkg, should that be necessary. > > Of course it's also possible to recover the old ebuilds and related > eclasses from Gentoo's tree repo (and/or gentoo/kde's git repo for the > overlay), if one wishes, but it's nice to know the data is available > locally too, as long as you still have the binpkgs, and it's often more > convenient to simply recover it that way. > >
I eclean'd it. I have a large drive my OS is on and no idea why I keep cleaning all that stuff out. I'll grow a brain one day and keep some of the stuff around. I did some poking around tho and found a config file with noaa in it. So, it seems odd that it doesn't work. Maybe the next release will have a fix. Dale :-) :-) ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
