First of all, there is nothing forcing anyone to use %autosetp, nor anything
preventing anyone from redefining %autosetp to whatever is wished, including
adding better diagnostics.
Meanwhile the flaw is in %setup through over-thinking, a design flaw that goes
back to at least 1997.
If you read the appendix that fully documents the %setup options, there is an
invocation of %setup that handles (by writing some shell commands) all known
usage cases: 20+ years of useful packaging shows that even if you consider the
implementation clunky and obscure and poorly documented (as I do).
There are several design flaws in %setup, the one exposed here is that
parameterized macro functions, implemented using getopt(3), cannot handle
multiple identical position sensitive option values.
Reimplementing parameterized macros using POPT, which can handle multiple
option values unlike getopt(3), and adding a means to handle named macro
tuples, to write some perfectly obvious and utterly trivial shell commands can
be attempted.
Meanwhile: why bother? The rpm macro implementation is receiving an increasing
number of bug reports, and useful extensions to automating checkouts with
multiple VCS systems are hardly used.
Rewrite the whole mess if %autosetup's inability to handle multiple option
values is deemed a show stopper sine qua non.
Or don't use %autosetup because it's known to be broken.
Or document the deficiency (though it's not at all clear where the %autosetup
deficiency should be documented).
Or live with the flaw and complain mightily that "RPM sucks because ..." every
other year or so, maintaining the status quo of open source development.
*shrug*
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/462#issuecomment-417054319
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
