[gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560710190236q3de96984h39a5a092c30b4528@××××××××××.com, 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

-- 
gentoo-amd64@g.o mailing list