[gentoo-amd64] Re: ~amd64 vs. ~x86

[Duncan]

Mark Knecht posted
<5bdc1c8b0511290336j39d95625g3f9d48b80d04827b@××××××××××.com>, excerpted
below,  on Tue, 29 Nov 2005 03:36:29 -0800:

> At the time I first built k3b on the system it seemed that ~amd64 didn't
> build. I tried ~x86 not knowing better and it did. I continued to use k3b
> that way successfully.
>
> Subsequent to this thread I changed it to ~amd64 last evening and it built
> fine. I have not used it yet, but as you say it's the same version so it
> should work.

It probably needed something else that you didn't have (that was/is still
marked ~arch for one or the other) the first time you tried it with
~amd64.  By the time you rebuilt it ~x86, you had it or it pulled it in
there.  Now that you have that dependency met, it of course builds on
~amd64 as well.

Note that those running full ~amd64 systems would likely have had the
dependency already merged, thus, it would build for them without the ~x86
intermediate step you took.

....

BTW, one of the reasons x86 and ~x86 are discouraged on an amd64 system (~
or stable) is because in some cases, keyword tests are used to determine
whether a particular portion is built 32-bit or 64-bit.  In particular,
(~)x86 keywording on some packages will cause them to try to build
portions of the package in 32-bit assembly.  Naturally, when the rest of
the package is 64-bit, this will cause serious problems, where it wouldn't
if the package was moved to overlay and (~)amd64 was added, because
that wouldn't trigger the 32-bit specific assembly coding, based
specifically on the (~)x86 keyword.

Most packages don't test on arch keywording specifically, or if they do
it's nothing related to amd64/x86 but rather endianness (as ppc) or other
arch-specific keywording related.  Thus, (~)x86 won't get you into trouble
with /most/ packages.  However, because the ones where it /will/ get you
in trouble tend to be core packages such as gcc, glibc, xorg, etc, and a
problem in /these/ packages could seriously break your system such that
it's difficult to recover without a fresh install, the recommendation is
not to use (~)x86 keywording at all.

For specific packages, therefore, you have two possible solutions.  The
recommended solution is to copy the ebuild to your overlay, add the
(~)amd64 keyword as appropriate, redigest, and try to merge the
rekeyworded copy.  However, if you are careful, and exercise some reason
as to just what you are keywording (~)x86 (don't do it with anything you
consider core, and preferrably take a look at the ebuild to see if it
does anything specific based on the x86 keyword), /then/ you can
reasonably safely add it to package.keywords as (~)x86.  However, this
latter method is /never/ recommended, and if something breaks anyway,
despite your cautions (or lack thereof), as they say, "You get to keep the
pieces!"

So anyway, that's why it seems to work for many individual packages. 
Whether it's worth the risk to you to do it that way, against
recommendations, is of course up to you, since it's your system.  

Now that you have it running with some (~)x86 package keywords,
personally, I'd simply ensure that the various (~)x86 package.keyword
entries were appropriately limited to the specific version you have
currently merged, limiting any future potential breakage, and run with it.
Over time, as new versions come out and are marked (~)amd64, you'll
upgrade to them, and eventually, you'll have a system entirely free of
your current (~)x86 packages.  The idea here is simply why worry about
what's working, and is similar to the approach of a stage-3 plus packages
Gentoo install, where individual site optimizations are only done in the
normal upgrade process.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list