Mark Knecht posted <[EMAIL PROTECTED]>, 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 -- [email protected] mailing list
