portage should be able to conditionally inherit eclasses by USE flags use perl && inherit perl-module isn't allowed because of dependancy caching I'm asking this because a lot of packages have false dependancies in darwin and ie. lirc has the same problem (with a dirty workaround).
maybe this would be easy to implement: inherit_use perl perl-modules PS. the objection for blindly inheriting is the (R)DEPEND from the eclass which is pulled into the ebuild
No... no no no no. :) eclasses set metadata, depends fex. there is no way to know if an eclass (that has changed) forces an ebuild to be regenerated (changed metadata) if you do conditional inherits. Look into glep 33, conditional elibs are valid, but conditional inherit's never will be.
that elib solution looks great! but what would be the best workaround for now? 1. wait until glep 33 gets into portage 2. copy eclass (elib like) code into ebuilds and drop inherit (lirc solution) 3. splitting eclasses into elib-eclasses / inherit-eclasses (sounds better)
could someone please say something about this? I will stop bugging after this comment.
Errr he already said that conditional inherits break the eclass cache. There cache that stores metadata for each ebuild and if that metadata is to change ( by not inheriting an eclass, for example, that the cache thought it did ) the cache becomes wrong and that leads to inconsistency and Bad Things(TM).
No workaround till g33 hits. Part of it comes down to portage's env handling- elibs *must* be preserved in the ebuild env (during building), something stable portage does not do. To get stable to do it, requires a fair amount of hackery, some details available via here- http://dev.gentoo.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt Short version is that there is a lot of work that goes into making g33 possible, without the internal changes to ebuild.sh, it's not possible to really do it. So... valid option? Wait for glep33. Working on it as we speak...