1 |
Am Donnerstag, den 26.03.2009, 19:12 +0100 schrieb Donnie Berkholz: |
2 |
> On 12:25 Mon 23 Mar , Robert Buchholz wrote: |
3 |
> > On Monday 23 March 2009, Tiziano Müller wrote: |
4 |
> > > Spec needed. DOCS or no DOCS? |
5 |
> > |
6 |
> > DOCS, and non-empty default value, please [1]. |
7 |
> > Some eclasses already do this (not base, but others), and if that |
8 |
> > default doesn't cover it for you, the function can be overridden. |
9 |
> > |
10 |
> > Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds |
11 |
> > brought up by Donnie: Our ebuilds always had declarative parts with an |
12 |
> > impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or |
13 |
> > look at the games eclass). |
14 |
> > I think if we stay within sane limits[2], following this paradigm is |
15 |
> > going to help developers because more simple cases will be caught by |
16 |
> > the default implementation without adding the complexities of having to |
17 |
> > know tons of (aka "more than one") variables and how they interact. |
18 |
> |
19 |
> I probably would have agreed with you a few EAPIs ago where stuff was |
20 |
> more painful. Take a look at this, though -- it doesn't seem so bad to |
21 |
> me in a non-DOCS, EAPI=3 world: |
22 |
> |
23 |
> src_install() { |
24 |
> default |
25 |
> dodoc foo bar |
26 |
> } |
27 |
> |
28 |
Well, we can just start with such a default src_install and then change |
29 |
it in a later EAPI if we see that it would be more useful to have |
30 |
DOCS="". |
31 |
|
32 |
But again: eclasses for certain package classes already provide |
33 |
src_install implementations considering DOCS for installing |
34 |
documentation. Which shows that some developers think it's useful. |