"Drake Donahue" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 24 Nov 2008 12:19:04 -0500:
> The wisdom of making currently existing and useful packages depend on > some future incomplete package management system (so that updates become > arduous and/or impossible)?? Anyone discovered a way to cope with > 'masked by eapx '? sys-apps/portage-2.2_rc15 did not relieve a 'masked > by eap2' .... It should be 2.2_rc16, now. rc15 has a circular logic bug on unsolved dependencies. But unless you happened to hit that bug, EAPI-2 should have worked, at least for anything in-tree and at least ~arch unmasked. I'm not sure why it wouldn't have and if it didn't it's certainly a bug, either in the package or in portage. Of course, overlays are an entirely different matter. In part, they are /intended/ to allow experimentation, and for the more experimental overlays, all bets and all guarantees are off. See below. But to answer your question, the EAPI restrictions work in stages, as follows: (1) Overlays can use whatever weird features they want, including ones only (for example) paludis supports, not portage at all. That's one of the reasons they are there, to allow the testing of experimental features. (2) In ordered to be unmasked to ~arch in the tree, the features used must be in a Gentoo council approved EAPI. The council has decided that it will only approve an EAPI (E-API, e being the traditional Gentoo prefix for package manager stuff and API having the traditional meaning) once it is concretely defined such that all three package managers agree on the definition, and when the official Gentoo PM, portage, supports it, at the same ~arch level as the packages depending on that EAPI. (3) No package using a new EAPI can go stable until the official package manager, portage, supports it in a stable version as well. If you are using overlay ebuilds, it's assumed you know how experimental that overlay is allowed to be and that you are willing to run an equally experimental package manager implementation of whatever features it uses. Gentoo neither can nor does attempt to make guarantees at that level. If you are using ~arch packages, there are limited guarantees attempted, but as the express purpose of ~arch is to allow packages intended for stable to be tested, but it's understood to be unstable and thus there will be bugs from time to time. Again, if you choose to use such packages, it's assumed you have your reasons and can manage to live with the consequences of the bugs that will occur. If you don't like those terms, only use stable, but be prepared to live with packages somewhat behind the times. In some cases, particularly with new hardware or with software that just added a very popular new feature, this will mean you'll simply do without support if you require that hardware support or feature to use the package, until the package works its way thru the system and is stabilized. Personally, I default to ~arch, and unmask hard-masked packages either in- tree or from various overlays from time to time as well. But in general, I'm prepared for them to fail once in awhile, and to spend sometimes significant time tracing and reporting bugs, then working around them or rolling back to an earlier version without the bug, should I need the bugged functionality. But YMMV definitely applies in this area, and while I'd not be satisfied running what I'd consider long outdated versions that may be the latest stable in many cases, other people may prefer that stability even if it does mean being maybe a year behind at times, possibly even more in some cases. -- 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
