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

[Beso]

2007/10/19, Duncan <1i5t5.duncan@×××.net>:
>
> 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.


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
>
> --
> gentoo-amd64@g.o mailing list
>
>


-- 
dott. ing. beso