2008/11/23 Duncan <[EMAIL PROTECTED]>: > Beso <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted > below, on Sun, 23 Nov 2008 11:03:36 +0000: > >> non ability for binpkg of paludis > > I've wondered about that. binpkg is a seriously used feature here, even > with just a single machine (well two now, but the second isn't running > Gentoo yet), as it plays a big part in both my backup and troubleshooting > routines. I've long argued that FEATURES=buildpkg is one of the most > undersold great features of portage, particularly since at its core it's > a simple bzip2ed tarball with a bit of extra data tacked on the end, so > it's easily worked with using virtually any *ix based archiver tools you > might prefer for exploration and/or extraction, emergency or otherwise. > > But as I've always said, he who writes the code, calls the shots, and > those writing the paludis code obviously don't consider binpkgs that > important, so the feature has yet to be implemented. > > Of course that has nothing to do with why I won't let it touch my system, > despite my extremely high respect for the devs' technical abilities. I'm > trying my best to stay nice here... > well, i don't want to start up a flame, but with portage i had very often issues with having the deps discovered in the right way. of course when the system is up and running this isn't so much of a trouble, but when you set it up or when you do an upgrade that still has quite some deps discovered then the problem is to be seen. of course the hour it takes paludis to build a dual core with 4 compilation jobs is to be considered. portage only takes less than 30secs to upgrade. well, anyway, i always find good having at least 2 working package installers on my system so that i can see out bugs for one or the other. also not using the binpkg feature if one of then fails then the problem is quite big.
-- dott. ing. beso
