[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist
From:       Kent Fredric <kentnl () gentoo ! org>
Date:       2016-09-21 10:03:57
Message-ID: 20160921220357.4d215e4f () katipo2 ! lan
[Download RAW message or body]


On Wed, 21 Sep 2016 08:44:33 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Obviously they could be identified by their explicit ${FILESDIR}.

My question is because I've had a difficulty understanding how repoman
"sees" the ebuild.

I was under the impression repoman would either have to rely on people to b=
e good
programmers and not do tricks like ${FILESDIR}/${MY_PN}-${PATCHLEVEL}.patch

( so that it could verify the part after the explicit filesdir variable
), or it would have to source the ebuild and expand variable
interpolations, and have some way of knowing *postinterpolation* what
the variables expanded to.

Given I think programmers *should* be allowed to use variables other
than "${FILESDIR}" in $PATCHES, it seems only reasonable that repoman
would need a post-interpolation way of checking they're all accounted
for.

Partly, because a certain usecase that would be good to guard against
is $PATCHES contains ${PV}, and the ebuild is bumped, and nobody
notices there is a patch that also needs bumping to keep that working.

Ideally committers should detect this when they compile their package
and the package explodes in src_prepare, but we do have a few cases
where people skip that stage and there's no safeguard, and autorepoman
can't even warn anyone that's happened as it doesn't poke into $PATCHES

( at least, irrc )


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]