Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 459692 - [Future EAPI] Provide a function, like dodocs(), to process DOCS= without calling `default`
Summary: [Future EAPI] Provide a function, like dodocs(), to process DOCS= without ca...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: in-eapi-6
Keywords:
: 468310 (view as bug list)
Depends on:
Blocks: future-eapi 483304
  Show dependency tree
 
Reported: 2013-02-28 11:00 UTC by Samuli Suominen
Modified: 2015-11-08 21:57 UTC (History)
4 users (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 Samuli Suominen gentoo-dev 2013-02-28 11:00:42 UTC
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
Comment 1 Samuli Suominen gentoo-dev 2013-02-28 11:01:44 UTC
I was referring to the unhandled bug 364343 from which we are still suffering, and the problem has become more wide spread.
Comment 2 Ulrich Müller gentoo-dev 2013-02-28 11:39:24 UTC
Can we extend the dodoc command? If called without any args, it could behave like the src_install default.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-28 15:21:30 UTC
(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.
Comment 4 Samuli Suominen gentoo-dev 2013-03-21 09:34:11 UTC
(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
Comment 5 Ulrich Müller gentoo-dev 2013-03-21 10:05:23 UTC
(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?
Comment 6 Samuli Suominen gentoo-dev 2013-03-21 10:07:06 UTC
(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
Comment 7 Ulrich Müller gentoo-dev 2014-10-02 18:57:16 UTC
*** Bug 468310 has been marked as a duplicate of this bug. ***