It is very laborious to maintain a Gentoo system with 'system' as x86 and 'world' minus 'system' (i.e., non-system packages) as ~x86 using the current system of keywords. The best way I know of to do so is as follows: 'emerge -Up world' to update everything x86, then use the script on stable.gentoo.org to find ~x86 packages, 'ACCEPT_KEYWORDS="~x86" emerge -up world' and select the packages that are ~x86 to upgrade to new ~x86 builds. It seems that many users may desire a way to run their system x86 and their non-system packages ~x86. This will allow them to nearly always have a working, bootable system (not considering unrelated problems) and yet run the most recent programs. My idea is to split ACCEPT_KEYWORDS into ACCEPT_SYSTEM and ACCEPT_NONSYSTEM (or something similar). This would allow ACCEPT_SYSTEM="x86" (AS=x86) and ACCEPT_NONSYSTEM="~x86" (ANS=~x86) for those who desire a stable system with new userland programs. AS=x86 and ANS=x86 would be for a full stable install. AS=~x86 and ANS=~x86 would be for a full 'testing-level' install. The fourth possibility, AS=~x86 and ANS=x86, should probably be discouraged through an error message of some sort as it doesn't make much sense, but it could be useful in testing the latest compilers, etc., with stable, generally known-to-work programs. Someone suggested the problem if a ANS=~x86 package desired a ~x86 system component. This should be generally disallowed unless AS=~x86 is set at the command line, similar to how ~x86 packages in general are emerged now. This would prevent the system from becoming unstable without obvious effort being expended to do so, whereas the current ACCEPT_KEYWORDS does not discriminate between system and non-system. A logical addition to this would be the ability to exclude packages from system, non-system or world. This would allow a few packages to be run ~x86 while the rest were x86. An interesting companion that would go with this is the ability to run everything ~x86 except for an exclusion list of packages that need to be compiled x86. Another logical addition would be the possibility of separate CFLAGS for system and non-system. Clearly, this would apply to all platforms, not just x86. To sum up, this would allow easy combination of an x86 system with an ~x86 non-system and many other combinations, including packages that could be excluded from either group. This would create a potentially more productive, more up-to-date, yet stable installation. Reproducible: Always Steps to Reproduce: 1. Desire to have ~x86 non-system, x86 system 2. Work way too hard to do so 3. Give up and file a bug report Actual Results: Difficult to run mixed system. Expected Results: Easy to administer mixed system.
I forgot to mention, of course this would be backwards-compatible. It wouldn't even be worth considering if it weren't. Users could choose to just use ACCEPT_KEYWORDS="~x86" to have the whole world set to it rather than ACCEPT_SYSTEM and ACCEPT_NONSYSTEM. rac made an excellent point in #gentoo. That is, sticky variables combined with scripts in gentoolkit could accomplish essentially the same thing. <rac> spyderous: for package in system; do echo "x86" >> /var/db/pkg/package/ACCEPT_KEYWORDS; done, then edit /etc/make.conf to have ACCEPT_KEYWORDS="~x86" <rac> spyderous: there will be troubles when dependent libs in system stay stable but apps go unstable, but that's pretty much unavoidable <rac> spyderous: i think it would be pretty straightforward to walk /etc/make.profile/packages to get a list of things in "system" <spyderous> rac: but i see your point. just do for packages in world; echo ~x86 > ACCEPT_KEYWORDS; for packages in system; echo x86 > ACCEPT_KEYWORDS (to have an x86 system, ~x86 non-system, then make.conf ACCEPT_KEYWORDS="~x86" has all new packages ~x86 as well) <spyderous> rac: different means to the same end, it seems. yours via scripts and mine via a couple of new variables. Basically either splitting ACCEPT_KEYWORDS and allowing exceptions will have the same function as sticky variables and some gentoolkit scripts. However, many gentoolkit tools are generally unknown so these options would probably be much less well-known than if they were variables. On the other hand, sticky variables would save people from having to keep a list of exceptions in make.conf. My proposal (new ACCEPT_KEYWORDS) is already made possible via a script on the forums which does 'world minus system' and allows exceptions in make.conf.
While I wouldn't want to automatically install all of "world minus system" as "~x86", I would like to do so for particular apps, like movie players, where new versions usually are better and stability is not a big issue. I wouldn't want to do so for, say, TeX, as I don't want to jeopardize my work. I propose that emerge gets a new switch whose effect would be to install the latest unstable version and its dependencies, where the versions of the dependencies are resolved as stable as possible (like "emerge some.ebuild" would do, not like "ACCEPT_KEYWORDS="~x86" emerge some" would). Crucially, the desire for an unstable version of that package would have to be recorded in the world file! "emerge -up world" would then notify the user of any new unstable version of those packages instead of wanting to downgrade the package because it is not stable. I think we should really learn from debian as far as mixing stable and unstable is concerned. Relating to your idea, there should probably be a warning when installing an unstable ebuild would imply upgrading a package in system to an unstable version. And (on a slightly different note) safe downgrading and safe unmerging should be implemented at last (meaning that before downgrading or removing a package, it should be checked whether downgrading/removal breaks dependencies of other packages)
Please see bug 13616. With that patch, you can create /etc/portage/package.keywords file and list the acceptable keywords on a per-package basis.
*** This bug has been marked as a duplicate of 13616 ***
