See the tracker. Please drop the eblit usage and inline the whole 50 lines of code into the ebuilds...
<QA hat> We will assume maintainer timeout in 30 days and inline the eblits into ebuilds if the issue is not solved until then. </QA hat>
autoconf only uses this variable for src_* funcs, and it deals with the scenario where it's undefined. so there's no violation here.
There is the following line in global scope: source "${FILESDIR}"/eblits/main.eblit || die Policy reference: http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12000011.1 Reopening.
(In reply to Ulrich Müller from comment #3) which is irrelevant. PMS says it's valid in src_* phases which is when it's used. it has logic already to handle other phases (i.e. it's undefined). there is 0 difference between this code and PATCHES=() referring to FILESDIR in global scope. you haven't provided any argument to the contrary.
Assigning PATCHES doesn't actually access the FILESDIR directory in global scope, but the code listed in comment 3 does.
(In reply to Ulrich Müller from comment #5) so your argument is that it is valid for a PMS to expand FILESDIR in global scope, and during src* phases, yet somehow the code can't actually look in there because it doesn't exist ? it just suddenly shows up when the src_* funcs execute ? that's a pathological case that no one implements because it makes no sense, and sounds more like an excuse to be uselessly pedantic in search of a non-existent problem. why aren't you banning code like this then: PATCHES=( "${FILESDIR}"/${P}-*.patch )
(In reply to Ulrich Müller from comment #5) or code like this: pkg_setup() { PATCHES=( "${FILESDIR}"/... ) } or code like this: pkg_postinst() { ewarn "$(<${FILESDIR}/README.security)" } seems like you're focusing on packages that don't have problems while ignoring ones that are actively broken.
(In reply to SpanKY from comment #7) > or code like this: > pkg_postinst() { > ewarn "$(<${FILESDIR}/README.security)" > } That's broken indeed, because the file may no longer exist at that point.
vapier, it would be much better if you spent your time fixing *your* bugs, rather than trying to divert the attention to others. And yes, those other things you point out are bugs and will be dealt with at some point. Feel free to report bugs for them. Nevertheless, finding more work for others doesn't imply you can ignore the big hack you've been pushing through for years and ignoring everyone else.
(In reply to Michał Górny from comment #9) you seem to be completely missing the point, and ignoring the points/questions that i posted. autoconf is not violating PMS, nor have you justified your claims, so there's nothing to "fix" here.
I will be pushing the posted changes shortly. However, before I do that I would like to reiterate a few points to avoid misunderstandings. 1. This bug has been open on 2016-06-19 (i.e. 278 days ago), which I presume is the time when you were officially informed of the PMS violation. You have been given a 30 day advance warning, and 7 day period to review the patches. During this time you have not raised any factual concerns about the proposed changes, nor shown any interest in solving the issue. Nevertheless, you have replied to this bug and the relevant threads, which I take as a confirmation that you have received the notices. 2. This action is performed on behalf of the QA team, using the power of maintainer override specified in GLEP 48. You have the right to appeal the QA action to the Council. 3. I should point out that whether you decide to appeal it or not, the QA resolution holds until it is overridden by the Council. You are not permitted to revert the QA commit, or to reintroduce the violation that it solved. If you find any issues with the pushed commits, you can ask the QA members to temporarily revert the change. However, you are not permitted to do that yourself without explicit QA approval. 4. I should point out that while the changes have been prepared and are being pushed on the basis of PMS violation, the relevant code is also violating the recent QA policy for ebuild code location [1]. I would like to explicitly ask you not to introduce any new code that violates this new policy. [1]:https://archives.gentoo.org/gentoo-dev/message/c036527c89c3cf1b303126cb849bf25a
commit a91f8fc1b6a4e72de75e50dc0579141ebb5122f1 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Thu Mar 16 09:32:14 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Fri Mar 24 20:39:30 2017 sys-devel/autoconf: [QA] Convert from eblits into an eclass, #586424 Convert the usage of eblits in sys-devel/autoconf into an equivalent eclass. This makes the ebuilds more readable, more predictable and fixes compliance with stricter versions of the package manager (i.e. a future release of Portage).
