[gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Sergio Polini <sp_rm_it@×××××.it> posted
200605281925.51615.sp_rm_it@×××××.it, excerpted below, on  Sun, 28 May
2006 19:25:51 +0200:

> Sure, but when I used FEATURES=buildpkg, emerge --sync took a long time;
> i.e. after emerging I was prompted to call fixpackages and it took a
> loooong time.

You gotta understand what they are saying that for and act accordingly.

What happens is that sometimes packages will move from one category to
another, or be renamed or replaced with something of a different name. 
When you sync the tree, portage gets a notice of the move and adjusts its
tracking of what you have merged (the /var/db/pkg database) to match
what's now in the tree.  In doing so, it not only adjusts the packages
that moved themselves, but the dependencies.

An example would be libgif/libungif.  A gif patent expired a year or two
ago.  While it was in force, libungif provided a patent-free workaround
for those in locations where the libgif package wasn't legal due to the
patent.  After it expired, there was no longer a need for a distinction,
as the libraries were designed to be drop-in replacements for each other,
only the one didn't include the patented functionality.  Thus, Gentoo was
able to remove libungif.  What they did was tell portage that libungif was
now libgif.

Because the libraries were drop-in replacements for each other, anything
that depended on libungif could now be changed to depend on libgif
instead.  The devs did that in-tree, but portage had to adjust its
dependency database so it didn't get out of sync with what the tree said
the dependency was supposed to be.

The catch is that binpackages include copies of the ebuild used to
create them, and said ebuild specifies dependencies.  In ordered to use
those packages with the updated tree, they too have to be updated.  This
takes awhile, as you noticed, so it's not handled automatically unless you
have FEATURES=fixpackages set.

The key thing to realize, however, is that as long as you aren't actually
trying to merge those binpkgs, they are fine as they are.  There's no
reason you have to run fixpackages every time something changes in portage
that asks you to, unless you are going to actually be using those binpkgs.

Further, in the event of a crash and a need to actually use those binpkgs,
you could use the manual untar method regardless of what the attached
ebuild said, because it bypasses that.  If you were actually using portage
to do remerge the binpkg, you could run fixpackages at that point, before
you actually remerged anything.  If you forgot to do so, it would simply
give you an error, which would probably get you thinking "Hey, I gotta run
fixpackages before this will work, as I had not yet done so."

As for the fixpackages process itself, you are absolutely correct,
currently stable portage (2.0.5x) takes a VERY VERY long time, because it
goes over EVERY SINGLE CHANGE EVER MADE EVERY SINGLE TIME YOU RUN THE
THING, even ones that were made the LAST time you ran fixpackages and thus
don't need to be made again, even ones made before you were even running
Gentoo, so there's no way they could ever apply to you! As such, with
stable portage, it's actually best NOT to run fixpackages until you have
to, because it redoes everything it did the last time anyway.

Fortunately, fixpackages is much smarter with the current ~arch portage
(2.1 release candidates ATM).  With 2.1, it timestamps the last time it ran
fixpackages, and skips everything before that, so it only processes what
has changed since the last time it ran.  Basically, that means that if you
run it every time it tells you to, it will only have the changes that
happened to come in with that portage sync to worry about, and it is MUCH
MUCH MUCH MUCH FASTER!!!  Usually, it only has a couple things to change,
instead of going thru the probably hundreds of changes that have happened
since the first move portage ever had.  As a result, it's actually
practical to add FEATURES=fixpackages now, and let portage manage it
automatically, as it's fast enough the sync normally takes longer than the
fixpackages does.  You can still do manually, and skip doing it until you
need to remerge one of those packages, if desired, but there's really no
need to do so.  Letting portage handle it automatically now actually makes
sense.

FWIW, 2.1 is targeted at stabilization for use with Gentoo 2006.1, which
is targeted for July.  This is only one of a number of HUGE improvements
in 2.1, and you guys still running 2.0.5x have a lot to look forward to
when 2.1 goes stable!  =8^)  Don't forget to reread the emerge manpage,
the make.conf manpage, and make.conf.example when it happens, as portage
will keep doing things the slow old way in a number of cases, if you don't
properly configure it to take advantage of the new features.  In
particular, pay attention to FEATURES=confcache (especially anyone using
KDE!) and FEATURES=-metadata-transfer (that one's on by default, so you
use - to turn it off, it's now faster to regenerate the metadata than it
is to transfer it, for many people).  FEATURES=parallel-fetch can also be
useful, and FEATURES=user-fetch is something anyone who has ever wondered
about the security implications of exposing root to the wilds of the net
during the fetch phase should definitely appreciate!  There's also a new
tool in the matching gentoolkit, also in -rc now.  It's called eclean and
it can be used to help clean out the staleness in both $DISTDIR (the
portage tarball cache location) and $PKGDIR.  There are also a couple
changes to the way emerge works.  The old way still works for 2.1 but will
be removed later, and portage now warns you if you use the old way. 
emerge actions (sync, metadata, fetch, etc) now want -- in front of them,
as emerge --sync, and a couple make.conf variables have changed their
name.  Again, the old way will still work for now, it just generates a
warning, so no worries, but there will be some things that you'll need to
change eventually, probably before 2.2.

That make things a bit clearer, now, and buildpkg a bit more tolerable? 
It should, as it certainly helps make buildpkg tolerable here!  =8^)



-- 
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