On 12/11/2017 02:23 PM, nicolas.mailhot@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
