Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 19 Oct 2007 11:36:53 +0200:
>> Talking about which... does paludis have proper binary package support >> yet? [...] Portage's FEATURES=buildpkg is my favorite underdocumented >> power-user portage feature > i don't know of that option being supported. i currently use the 0.24.6 > from august and that don't seem to list that feature. what does that > feature in portage?! Simply put, it automatically creates tarballed binary packages every time it emerges something, storing those binary packages by default in $PORTDIR/packages. That way, should you ever need to remerge that package-version (say on another machine if you have more than one, or if you need to revert to an old version because the new version you just merged doesn't work for some reason), you can do so using emerge -- usepackage (or --usepackageonly), and it'll grab the binary package you created the first time, merging it much faster since it doesn't have to recompile anything. IOW, except for the first time you merge a package, it's as if you were using a binary distribution, except you created and customized the binaries yourself, using Gentoo's usual features. Of course, the first time, the package is compiled as it normally is, so there's no direct advantage there -- but it can still be useful. Obviously, the folks that will get the most use out of this are the folks running several similarly configured machines, same USE flags, etc, since they can then compile once and merge the same binary package on all their machines. However, it's quite useful even if you run only a single machine, as I do here. As I said, it's helpful if you need to remerge a package for some reason. I've reinstalled from my binpkgs once after a problem with disk corruption, and it goes MUCH faster. Also, because the packages are basically tar.bz2s with a bit of extra metadata glued onto the end, they can be browsed with your favorite archiver (I use mc, as I do for many of my sysadmin tasks), and it's easy to retrieve just a single file, say a config file you screwed up and want to start over with. The binpkgs are also useful for comparing the contents of packages between versions -- I've filed and had fixed a couple bugs because new versions ended up missing some file or another, for some reason, caught because once I figured out something was wrong, it was easy to compare the files in an older working version with the files in the newer broken version. The format also allows one to fix a broken portage or python. Consider how you'd emerge a package if your package manager is broken. With automatically created tarballs, it's easy. Simply backup any config files you want to save, and untar the working version directly on top of the live root filesystem. (Or, if it's /really/ broken, and tar and/or bzip2 are dead as well, boot your recovery disk and use the tar and bzip2 from there to do the job.) The metadata glued onto the tarball includes the ebuild itself, and that can also be handy. What do you do if you use a package that gets removed from the tree (for example, xmms)? Well, as long as you still have the binpkg around, you still have a copy of the ebuild, and can copy it to your overlay and continue to use it from there, even rebuilding if necessary (say if you upgrade gcc), even after the copy in the tree is long gone. So it's not just the binary packages, useful enough in their role as backups as it is, but the fact that the data in those packages can still be accessed with ordinary tools like tar and bzip2, that makes portage's binpkgs so useful. If an alternative package manager supported binpkgs, I'd hope it used something equally accessible with standard tools. > i'm using paludis for a speed reason. portage is really really slow and > it makes you die before determining deps. it's awful in that terms. I've found that to be true only for the first "cold cache" run, when it has to read everything in from disk. Once the data is in cache, portage is MUCH faster. With a gig of memory, it should be in cache pretty much as long as you are using it, tho if you go a few days between using portage, or if you reboot, the data will probably be flushed from cache and need to be read in from slow disk once again. With a couple gigs, it's likely you'll only have to do that initial portage run once, and after that it'll remain in memory until the next reboot. With the 8 gigs of memory I have... lets just say I normally don't worry about it, tho that first emerge --pretend world I run does take a bit. Of course, syncing also takes a bit, but that's not too terribly often either, compared to the number of times you might actually run emerge in a session. So speed isn't the problem for me it is for some. > i > foud out paludis which has a great speed and that seems to give a lot of > debug infos and that has a more modular approach when compared to > portage. the last useful thing is that i with portage i used to get some > times compilation errors that would go away when resuming; this thing > don't happen almost anytime with paludis. The more modular is of course good on its own merits, as is faster, tho I explained that's not a big problem for me here. As for compilation errors, I don't tend to get any of those that go away on resume, altho there was a bit of an order resolving problem in ~arch portage for a few months that caused a few issues. However, I'm pretty religious about running --newuse and --deep (both run by default on my --update world runs), and --depclean and revdep-rebuild as well. That likely has a lot to do with it, as my dependencies are going to be quite a bit cleaner than someone who doesn't routinely practice "good package hygiene". =8^) In any case, as I said, unless a package manager has good binary package support, there's little chance of me seriously considering it. Thus the question, since the lack of such binary package support is what ended my initial paludis investigation back then. Of course, different strokes for different folks and all that, and what works so well for me may indeed be intolerable for you, so as they say, YMMV. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
