| 1 |
>>>>> On Tue, 27 Aug 2013, Ian Stakenvicius wrote: |
| 2 |
|
| 3 |
> On 27/08/13 05:59 AM, Ulrich Mueller wrote: |
| 4 |
>> In a nutshell: The default src_install() implementation in EAPIs 4 |
| 5 |
>> and 5 is flawed because it doesn't account for the DOCS variable |
| 6 |
>> being defined but empty. It ends up calling dodoc without any |
| 7 |
>> arguments in this case. This will work in Portage (with a QA |
| 8 |
>> warning), but the stricter implementation in Paludis will error |
| 9 |
>> out. |
| 10 |
>> |
| 11 |
>> 2. There is consensus that default src_install should be fixed in |
| 12 |
>> the next EAPI. The question is if we should retroactively change |
| 13 |
>> the specification [3]. |
| 14 |
|
| 15 |
> (Replying to original list -- are we supposed to move these |
| 16 |
> discussions to -dev@ ??) |
| 17 |
|
| 18 |
Yes, when they are of a technical nature. |
| 19 |
|
| 20 |
> It's unfortunate that this bug is there (DOCS must always have a |
| 21 |
> value in the default src_install, whether it be set by the default |
| 22 |
> phase or in the ebuild), |
| 23 |
|
| 24 |
The scope of the issue is more limited. If the ebuild doesn't define |
| 25 |
DOCS at all, then the default src_install works just fine. The problem |
| 26 |
arises only if the ebuild explicitly assigns an empty DOCS=() or |
| 27 |
DOCS="". Very few ebuilds, less than 20 in the tree, are doing this. |
| 28 |
See ssuominen's list: https://bugs.gentoo.org/show_bug.cgi?id=480892#c3 |
| 29 |
(And we already know that it contains some false positives.) |
| 30 |
|
| 31 |
> but I don't think we can just retroactively fix EAPI4/5 to do it |
| 32 |
> without consensus from all of the PM implementation upstreams. |
| 33 |
> Inviting them all to the council meeting to seek their approval is |
| 34 |
> always a possibility, of course. |
| 35 |
|
| 36 |
Zac has already approved it here: |
| 37 |
https://bugs.gentoo.org/show_bug.cgi?id=481664#c38 |
| 38 |
And so far, I haven't seen any opposition from Paludis authors. |
| 39 |
|
| 40 |
> It would probably be best to just enforce workarounds in eclasses |
| 41 |
> and remove the empty/null assignments in ebuilds, and make sure the |
| 42 |
> spec (and therefore PMs) are fixed to allow empty DOCS in EAPI6 and |
| 43 |
> above. |
| 44 |
|
| 45 |
I believe that we should do that in any case. But see mgorny's |
| 46 |
proposal for an einstalldocs function. |
| 47 |
|
| 48 |
Ulrich |
Archives