[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: [gentoo-dev] Default src_install and empty DOCS (was: Call for agenda items - Council meeting 2013-0
From: Ulrich Mueller <ulm () gentoo ! org>
Date: 2013-08-27 15:06:38
Message-ID: 21020.49278.455167.739847 () a1i15 ! kph ! uni-mainz ! de
[Download RAW message or body]
>>>>> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic