On Tuesday 03 November 2009 18:27:46 Sebastian Pipping wrote: > Patrick Lauer wrote: > > Hi there, > > > > a while ago Thilo Bangert spent quite some time on filing lots of bugs. > > While I appreciate such QA efforts I don't agree with those bugs at all. > > > > All of these bugs were for the use of the FEATURES variable in ebuilds, > > which is a very convenient thing to work around issues. > > For example known failures with FEATURE="distcc" or funky things like > > test failures with FEATURES="userpriv" and so on. All other methods of > > expressing that are much more verbose and inherently sucky. > > What other methods are there?
For distcc, you could try some random things like checking the CC variable or such. All inherently unreliable methods to guess if the FEATURE variable contains a certain string. Userpriv I've seen the funny idea to check if UID=0 and such. I'd guess for every FEATURE there's a similarly confused method to guess if it is enabled or disabled, instead of just checking the friggin variable. > > > One example of such a bug is > > https://bugs.gentoo.org/show_bug.cgi?id=278960 for those too lazy to > > search. > > For that very case I remember that "test" is a global use flag as well > and that therefore at least > > if hasq test ${FEATURES} ; then > [..] > fi > > has a cleaner use-flag-based equivalent. > > # euse -i test > global use flags (searching: test) > ************************************************************ > [- ] test - Workaround to pull in packages needed to run with > FEATURES=test. Portage-2.1.2 handles this internally, > so don't set it in make.conf/package.use anymore That's a creative way to use a side-effect to check. Assumes that the package uses that useflag though, what about the case where you want to conditionally change a file (or maybe delete it or whatever) in src_prepare when FEATURES="test" is set, but USE="test" is not needed? In short, stop complexifying things. > > > To quote: > > "FEATURES is a portage specific package manager configuration variable > > not specified in PMS and cannot reliably be used in ebuilds or eclasses." > > Makes sense to me atm. Makes no sense to me, but then I seem to be special :) > My opinion is: please stop dissing PMS, it doesn't help anybody. > I have requested that from you before. It's still broken. It doesn't document reality. It's not useful as an implementation guideline or as a reference how to do things. In short, it sucks badly. And all my attempts to get it fixed have been deflected, so I'll keep ridiculing it until it stops being a failwhale. After all I'm here to participate in the bestest distro ever, so we deserve correct and consistent documentation. > Would a patch for the next EAPI theoretically impossible? I absolutely fail to see how that helps the current situation. EAPI is not the right answer to every question. :) Have fun, Patrick
