Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 100503 - conditional inherit
Summary: conditional inherit
Status: RESOLVED INVALID
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement
Assignee: Portage team
URL: http://www.gentoo.org/proj/en/glep/gl...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-27 11:45 UTC by Dick Marinus
Modified: 2005-08-02 16:54 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Marinus 2005-07-27 11:45:37 UTC
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).
Comment 1 Dick Marinus 2005-07-27 12:40:08 UTC
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
Comment 2 Brian Harring (RETIRED) gentoo-dev 2005-07-27 21:49:38 UTC
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.
Comment 3 Dick Marinus 2005-07-28 03:42:56 UTC
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) 
Comment 4 Dick Marinus 2005-08-02 00:34:23 UTC
could someone please say something about this?

I will stop bugging after this comment.
Comment 5 Alec Warner (RETIRED) archtester gentoo-dev Security 2005-08-02 04:45:37 UTC
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).
Comment 6 Brian Harring (RETIRED) gentoo-dev 2005-08-02 16:54:50 UTC
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...