On Tue, 2007-11-13 at 20:31 +0000, Ciaran McCreesh wrote: > That was only the case because previously, using new features that > Portage didn't support would cause horrible breakage. Now, instead, the > ebuilds show up as being masked.
...which is just as good as "broken" when it happens to a new user first installing Gentoo and wondering why he can't even follow the directions in the Handbook. What brought me to bring this up was the mention of changing of eclasses which support a large number of ebuilds, effectively masking a significant portion of the tree from our users. Let's say that I added EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 feature in one of the functions. Guess what? I've now managed to mask *portage* for users of older portage versions. In fact, I've managed to mask paludis and pkgcore, too. Yes, this is an extreme example. Yes, it is completely possible. Yes, that user would be completely screwed. > > Now, this isn't so much of an issue with individual ebuilds, but > > you're talking about changing how the Java eclasses work, essentially > > blocking *anyone* using an older portage (including everyone > > installing from 2007.0 media) from using any package which inherits > > the eclass. > > They just need to upgrade their package manager first. Easy. Expecting users to do pretty much anything on their own is broken behavior and should not be relied on for package manager compatibility. > > Also, we should really think about this sort of thing before we start > > using it. How are we going to support EAPI changes in eclasses? What > > if I have an eclass with EAPI=1 features and I want to add some EAPI=2 > > features? I think allowing EAPI=* globally in an eclass should be > > prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, > > only. > > Doing an entire eclass for one specific EAPI generally isn't a good idea > since it's fairly likely that EAPI bumps will be a fairly common thing. > > > In other words, you'd need new EAPI=1 eclasses for your EAPI=1 > > ebuilds. Either that, or some way to say something like: "execute > > code path A for EAPI=0 and execute code path B for EAPI=1" or > > something similar. I would suspect that the "best" current solution > > is to check EAPI in the individual functions and perform the right > > actions based on those functions, rather than marking an entire > > eclass. After all, only EAPI=* functions need to be "hidden" behind > > EAPI. > > A solution with EAPI-agnostic code in foo-common.eclass and > EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more > readable and maintainable in most cases. Umm... So in the paragraph above, you say an EAPI-specific eclass isn't a good idea, and here you push it as the proposed solution. Huh? Consistency, please... I guess my real point is that we need to be *really* careful when using this stuff. It is *not* as simple as you make it out to sound. All it takes is one person adding an EAPI into an eclass somewhere to completely screw over a *huge* number of our users. I am just trying to point this out and hopefully get discussion going on how to utilize these great new features without potentially causing damage to our user's machines and our reputation. I still think that EAPI should not be allowed to be set in an eclass globally. All I can see is it causing problems for tons of users who don't have a clue what is happening to their systems. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
