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