| Summary: | RFE: per-package 'eclasses' | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | SpanKY <vapier> |
| Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | flash3001, m.debruijne, solar, tove |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Any reason we could not put a class in $FILESDIR/blah And then just source $FILESDIR/blah.(eclass|sh) ? that was suggested by someone before but i'd prefer to have someone on the portage team say that method is 'OK' before i start doing it Please take Bug 46223 into consideration. Right now, we "cannot" remove an eclass, just because no ebuild in cvs needs it anymore. I bet, local eclasses would be more often modified/replaced by others, than global ones, so it'll become a more visible problem. actually, that brings up another point ... binary packages wouldnt work correctly because $FILESDIR is not availabe when using them This is covered with Brian's eclass/elib GLEP (which includes per-package stuff too now). Using UPSTREAM, because most of the LATER ones will be reopened again. |
when dealing with packages whose ebuilds are large (often times 200 or more lines each) and we have to keep multiple versions around (SLOT-ed packages with many SLOTs, binutils, gcc, glibc, etc...), it'd be nice to create an 'eclass' of sorts just for that one package that way we wouldnt have to try to keep changes in sync across many versions ... this is a puge pita, especially when the changes can be large i was thinking of perhaps a reserved inherit keyword like 'local' ... if you have something like 'inherit local', portage would look for ${PN}.eclass in the same directory as the ebuild