[gentoo-amd64] Re: quickpkg problems

[Duncan]

Michael George <george@××××××××××.com> posted
20070103030310.GA3184@××××××××××××.office, excerpted below, on  Tue, 02
Jan 2007 22:03:10 -0500:

> I'm updating my system with my normal CHROOT method where I update all
> teh packages in a CHROOT and then make packages of them for my real
> system.
>
> For the first time, I am doing this to my amd64 system rather than my
> x86 system, and I've had a couple glitches.
>
> Because /lib and /usr/lib are symlinked to /lib64 and /usr/lib64, the
> packages I made in my CHROOT won't extract correctly.  It will get to
> extracting /lib (or /usr/lib), which is a symlink, and it cannot create
> the next level of directories within it because the referenced directory
> doesn't exist where the package is being extracted.
>
> Am I doing something wrong in creating the packages, or in extracting
> them?

Have you tried FEATURES=buildpkg ?  That would seem to be what you are
after, and should avoid the system-specific aspects of doing it
after-the-fact with quickpkg.

The issue is that since quickpkg uses what's actually on the system (or in
the root) the package is created on, it will by definition include certain
system-specific aspects in the packages as built.  Among these are
system-specific configuration details such as customized config files and
system dirs vs. symlinks.

FEATURES=buildpkg is designed to avoid the system-specific aspects
while still retaining build flag and USE flag aspects, by binpkging the
image as it is fake-installed directly into the temporary image
post-install pre-qmerge stage (see the ebuild (1) manpage if you aren't
familiar with ebuild stages).  Thus, it is the package as it was built,
pre-system-specific-configuration, since it's before qmerge and therefore
before etc-update.  It's also as fake-installed to the temporary location,
so the only symlinks included should be the symlinks in the actual
package, not anything from the system it's merged to, as will unavoidably
be the case with quickpkg.

FEATURES=buildpkg also tests the binary package by actually merging from
the tarball instead of qmerging from the fake-install image.  While that
test is by necessity on the system that just built the package, thus not
catching all system-specific dependency problems, it at least demonstrates
that the created binpkg can be successfully merged under the right
conditions, a test missing entirely from the quickpkg method.

quickpkg is really designed as a way to avoid a recompile if one is
testing an unmerge or upgrade one isn't sure about, in the case the test
upgrade does indeed prove unstable or the unmerge ill advised, thus
avoiding having to recompile the package you just had merged before the
test.  While it /can/ be used to transfer packages between systems, thus
avoiding the recompile on the other system, that isn't its main intent,
and there are certain occasional issues that have to be resolved manually
as a result when it is used in that manner.  

If one is going to be doing routine package transfers as a matter of
course, it's therefore far better to use FEATURES=buildpkg, avoiding at
least /some/ of the problems.  The problems that FEATURES=buildpkg doesn't
resolve technically, and there are a number of them that remain as current
limitations of the way portage itself functions, Gentoo devs usually
nullify thru other means.  Very occasionally, there will be a bug or two
with a FEATURES=buildpkg built package merging, but where there is, it
should be reported (at bugs.gentoo.org, be sure to search and see if
the bug has already been filed by someon else) as exactly that, and it
should be fixed eventually and if it'll take awhile, the Gentoo package
maintainer or portage devs will often provide a workaround to get you
moving again.

BTW, I recommend FEATURES=buildpkg as one of the poorest advertised
"power" features of portage, even for users with only a single
installation.  The backups it provides certainly simplifies routine
sysadmin chores and troubleshooting in a number of ways.  Among others,
it's /tremendously/ easier to recover from a borked gcc or portage or
python, in addition to the fact that it becomes a matter of five or ten
minutes' work to merge a different version of a package once you have
several binpkged versions available, to see if a particular problem is
with one version or all of them.  Since the original as-merged version of
any file is saved in the binpkg, it's also extremely easy to compare a
config file as it currently exists on the system to what was originally
merged.  As I said, truly an under-appreciated and therefore underutilized
power-feature of portage!

FWIW, I keep my binpkgs on a dedicated partition, 4 gig sized for plenty
of room tho I had it on a 2 gig partition previously.  The actual size of
a full operating set of merged packages, binpkged, is somewhere around
half a gig, here, I'd guess, but as I said, it's convenient to keep
several versions of packages around, and while portage now includes the
eclean tool to help manage the packages and distdir dirs, one doesn't want
to have to clean them out all /that/ often, so over 2 gigs is recommended,
with my 4 gig being plenty and to spare, so I'd say 3 gigs.

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