Ciaran McCreesh wrote: > You can't sensibly have backwards compatibility across new deps if all > the requested options are implemented anyway -- there's no exact > mapping between the current three vars and all the new ones. New deps > has to be an EAPI change, and it has to be an ebuild change.
for the ones I pointed it is ^^; > And the other problem -- we'd be talking hundreds of variables. hundreds -> bad, no matter what. > Multiply number of dep types (build, run, install, compile against, > post, probably more) by number of requirement levels (required, > suggested, recommended) by number of ABI combinations by number of > system combinations by whatever else ends up being useful. I'm against suggested and recommended. I don't like it in debian and I won't like it in gentoo. the rest shouldn't interest an ebuild by itself but should be handled by the package manager. >> every autostuff ebuild should and that's a start. > > Except that autotools doesn't have any sane way of handling chost / > cbuild / ctarget for non-trivial packages. If you want to do something > simple like generate a file using a program you make at compile time, > you're forced to resort to nicking insane hackery from the gcc build > system -- or you can do what most people do and just break non-native > compiles. Using autotools does not mean supporting chost / cbuild / > ctarget properly... bad users of tools are always present, by itself autotools gives support and usually works out of box. > Tree branching will very quickly become unmanageable. Users will be > forced to choose a branch, but useful features will be spread across > different branches. Only if you don't manage it correctly. I know what I'm doing on linux and it is _quite_ branched. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
