On Mon, Dec 11, 2017 at 01:23:19PM +0100, nicolas.mailhot(a)laposte.net wrote:
> And the issue you're having that requires %setupargs is not a problem
> in RPM 4.14
I don't have an issue with %setupargs, I have an issue with requiring packagers to
change stuff in the spec header *and*
at %prep level, which is not in the same place of the spec. That is something which has
wasted huge quantities of man-hours in the past, even for experienced packagers.
The automation knows how the downloaded source archive will be named, what is the
structure of the source archive (the arguments that need passing to %setup for this
archive). The question is just how to pass that knowledge from the automation macro call
to %setup or %autosetup.
Overriding %setup makes this work transparently with little risk.
If there is a strong opposition to that what is the best way to achieve the same result?
Using a specific setup-ish macro name like suggested by Panu is trivial technically but
has the huge drawback that it requires a specific call by the packager (and many will
forget it, at least as first). So it de-optimizes the packager workflow. I'd frankly
prefer to optimize the packager workflow over helping tooling – that's what costs
actual money and potential contributors.
I think it's OK. After all you already require a specific '%setup -n
invocation (<arg> in this case is different then the github default), and
setting a few different fields in a specific order. So in practice people
are going to go by the template provided in the docs, and whether it's
%setup -n something or %forgesetup doesn't make much difference.