On Wednesday 16 February 2005 13:20, Brian Harring wrote:
> Basically, you can't do
> if [[ $SOME_VAR == "blah" ]]; then
> func something() { echo "yay"; };
> else
> func something() { echo "nay"; };
> fi
> The exported functions from an elib need to be constant- no varying the
> 'api' dependant on external vars (which some current eclasses do).
Understood. The GLEP's wording should be fixed.> Err. Damn, good question, hadn't clarified it- with the next major release > of portage the env will be generated -once-, during the setup phase. So > essentially, you can conditionally pull in an elib at the global scope > (evil), or w/in pkg_setup (preferable). Pulling in during pkg_setup isn't > totally optimal for binpkgs, but that can be handled (just have the env > 'know' what elibs it has pulled in). The only thing the GLEP says about pkg_setup is: "Execute only what must be executed in the global scope. Any code executed in the global scope that is related to configuring/building the package must be placed in pkg_setup." Currently AFAIK eclasses are always inherited in general scope. Is there a reason to import elibs in pkg_setup instead? Can it even be done with eclasses (which might affect metadata variables)? Or does your statement that it's evil only refer to conditional imports? > Leaving unsigned eclasses sitting in the tree is an equally ugly solution, > as is even allowing for them to be used after the eclass devs have > basically abandoned them. They aren't needed in the tree after all ebuilds > have been migrated, so why should -all- users have to suffer syncing them? > They're outdated. They're cruft. > > Sidenote, the users getting into an uproar over eclass-compat likely are > doing something they shouldn't be. The glep proposes adding it to the > system profiles (I clarified on this in an earlier email to -dev btw), > which means unless the users have done something -dumb- like --inject'ing > the pkg themselves, they won't even see horkage from it. OK, after rereading the GLEP I agree. Sorry, I didn't fully realize you were going to put it in all profiles. In that case it's transparent and you shold do whatever is easiest for you (as Portage devs). Although I still don't see that leaving a few dozen unused files in the tree is so terrible *shrug* -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpDtr04XUJ49.pgp
Description: PGP signature
