| Summary: | [Future EAPI] Provide a function, like dodocs(), to process DOCS= without calling `default` | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Samuli Suominen (RETIRED) <ssuominen> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | esigra, hasufell, jlec, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=364343 https://bugs.gentoo.org/show_bug.cgi?id=394211 |
||
| Whiteboard: | in-eapi-6 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380, 483304 | ||
I was referring to the unhandled bug 364343 from which we are still suffering, and the problem has become more wide spread. Can we extend the dodoc command? If called without any args, it could behave like the src_install default. (In reply to comment #2) > Can we extend the dodoc command? If called without any args, it could behave > like the src_install default. Please don't. I think that would be almost like putting two different PMS sections together. (In reply to comment #2) > Can we extend the dodoc command? If called without any args, it could behave > like the src_install default. sounds good to me, dodoc or dodocs, that's just bikeshedding, both are acceptable imho would be nice to get this bug finally handled, the use of calling `default` in ebuilds around the tree is increasing by the day bug 364343 can be closed with wontfix then, imho (In reply to comment #4) > sounds good to me, dodoc or dodocs, that's just bikeshedding, both are > acceptable imho Call it bikeshedding, but the other do* commands accept a list of arguments, and are typically paired with a new* command. This is not the case here. Also having both "dodoc" and "dodocs" is confusing. edocs? einstalldocs? (In reply to comment #5) > (In reply to comment #4) > > sounds good to me, dodoc or dodocs, that's just bikeshedding, both are > > acceptable imho > > Call it bikeshedding, but the other do* commands accept a list of arguments, > and are typically paired with a new* command. This is not the case here. > Also having both "dodoc" and "dodocs" is confusing. > > edocs? einstalldocs? if it has to be one of those twos, please keep it short, so then edocs but i still like dodocs much more and find it less confusing *** Bug 468310 has been marked as a duplicate of this bug. *** |
Use case 1: ----------- Í proposed earlier that if `default` would accept args, or have some other way of handling the "foobardir" piece of this... emake DESTDIR="${D}" foobardir="/foo" install But that was rejected. So now when we have ebuild with: DOCS="foobar* foo" src_install() { default echo do_something_else } So this gets now converted to: src_install() { emake DESTDIR="${D}" foobar="/barfoo" install dodoc foobar* foo echo do_something_else } So I'm suggesting a function to handle the DOCS= be it "" or () like: DOCS="foobar* foo" src_install() { emake DESTDIR="${D}" foobar="/barfoo" install dodocs echo do_something_else } Use case 2: ----------- Multiple eclasses bundle the DOCS= code from Portage's code, and it's not even consistent between eclasses, so some eclasses work with DOCS="" and some don't, some work with DOCS=() and some don't. If there was a way to call PM to handle DOCS= this wouldn't be a issue and the duplicate code could be deleted from eclasses