2007/10/19, Duncan <[EMAIL PROTECTED]>: > > 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.
this could be an interesting feature and could have you do a full system backup. > 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 have a notebook that i usually shut down more than 3-4 times/day and the chache problem for me is fundamental. i don't have to wait for portage almost 7minutes for a world preview update while paludis does it in less than 2min. > 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. fortunately i still run both packages and have paludis --report the state of the system then portage to depclean and see if there are differences. i didn't find to have problems of orphaned or other problems of package management. the one interesting function that i'd like to test is the parallel compilation feature, which i happened to find by chance in the forum. a patch that allows portage to compile more packages at the same time if the second package compiled does not trigger an installation of the first one. for example i could compile gimp and knetworkmanager at the same time if i had a good processor. -- > 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 > > -- dott. ing. beso
