On 12/11/2017 02:23 PM, nicolas.mail...@laposte.net wrote:
Hi Neal,
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.
They only need to change %prep once. Which they do at the time they
learn how to use these new macros anyway.
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.
If there is now way to do it cleanly or safely in rpm, I'll de-optimize the
packager side. I don't want to cause problems to anyone. But that would be
pretty sad.
Specific functionality requiring explicit invocation is better than
feeble magic built on loopholes (that will eventually be closed anyway)
On a more constructive note, I'd think conceptually this might better
fit into %autosetup territory. Have you looked at extending that, rather
than overriding/building something separate?
- Panu -
Regards,
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
