Currently prepalldocs excludes automatically "html" subdirectory, I would like it to be able to add other subdirectories. Something like: DOCS_EXCLUDE="d1 d2 d3" prepalldocs Should be simple addition of for loop. Thanks!
Created attachment 108318 [details] prepalldocs DOCS_EXCLUDE is a crappy variable name ... perhaps a better method would be to pass it them in as arguments: prepalldocs -x d1 -x d2 -x d3 either way, here's an easy way of doing this
Thanks for quick response! Waiting to use this... :)
Hello, Is there target version/revision for this?
Maybe also add an optional argument of a directory to prep... So it can be used for other locations as well... Just curios... Why a simple patch as this one is sitting so long opened? Is there something wrong with the request?
For interface changes within the ebuild environment, it's best to version them via EAPI. The next best alternative is to make ebuilds depend on a version of portage that supports the required interfaces, but that's a poor substitute for EAPI. See bug 179380 for a similar situation.
Thanks, But this does not change the interface. The default behavior is the same. But OK... We will wait.
(In reply to comment #6) > Thanks, > But this does not change the interface. The default behavior is the same. An extension is also a change to the interface (ebuilds relying on the extension may not work correctly with portage versions not having that extension). That said, it could be handled with a portage dep in this case, but that wouldn't be nice to non-portage users.
prep* shouldn't be in ebuilds or PMS anyway...
incorrect as already noted on the gentoo-dev mailing list there is no clean way to get the functionality of `prepalldocs` other than `prepalldocs` most prep* functions are transparent, but many of them need to be in EAPI-0
What about EAPI-1?
I guess this one will have to wait until EAPI-2 since EAPI-1 is already defined (bug #194876). It wouldn't set a very good precedent if we were to go and change the definition now (even though >=sys-apps/portage-2.1.3.12 hasn't been marked stable yet). For inclusion, I think we should update the patch to use some kind of command argument interface as suggested in comment #1 since the environment variable approach seems unclean (why pollute the environment with yet another variable).
This is obsoleted by bug 260118 I'd say. *** This bug has been marked as a duplicate of bug 260118 ***
