| 1 |
On Wed, 21 Sep 2016 08:44:33 +0200 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
|
| 4 |
> Obviously they could be identified by their explicit ${FILESDIR}. |
| 5 |
|
| 6 |
My question is because I've had a difficulty understanding how repoman |
| 7 |
"sees" the ebuild. |
| 8 |
|
| 9 |
I was under the impression repoman would either have to rely on people to be good |
| 10 |
programmers and not do tricks like ${FILESDIR}/${MY_PN}-${PATCHLEVEL}.patch |
| 11 |
|
| 12 |
( so that it could verify the part after the explicit filesdir variable |
| 13 |
), or it would have to source the ebuild and expand variable |
| 14 |
interpolations, and have some way of knowing *postinterpolation* what |
| 15 |
the variables expanded to. |
| 16 |
|
| 17 |
Given I think programmers *should* be allowed to use variables other |
| 18 |
than "${FILESDIR}" in $PATCHES, it seems only reasonable that repoman |
| 19 |
would need a post-interpolation way of checking they're all accounted |
| 20 |
for. |
| 21 |
|
| 22 |
Partly, because a certain usecase that would be good to guard against |
| 23 |
is $PATCHES contains ${PV}, and the ebuild is bumped, and nobody |
| 24 |
notices there is a patch that also needs bumping to keep that working. |
| 25 |
|
| 26 |
Ideally committers should detect this when they compile their package |
| 27 |
and the package explodes in src_prepare, but we do have a few cases |
| 28 |
where people skip that stage and there's no safeguard, and autorepoman |
| 29 |
can't even warn anyone that's happened as it doesn't poke into $PATCHES |
| 30 |
|
| 31 |
( at least, irrc ) |
Archives