Summary: | How to mix system x86 and non-system ~x86, plus more | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Donnie Berkholz (RETIRED) <dberkholz> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | CC: | docs-team |
Priority: | High | ||
Version: | 2.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Donnie Berkholz (RETIRED)
2003-05-22 03:26:45 UTC
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. |