[Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)

[nim-nim]

Panu, one huge reason `%setup` is still a mess after all this time it that it is linked to the `SourceX` black magic. And yes rpmbuild will complain loudly if you deviate from the way it thinks things should be done. And yes it will refuse to process the resulting spec. And the documentation is piss-poor. 

There are layers over layers of workarounds in `SourceX` and `%setup` just to avoid admitting parts of the original rpm design didn't work out in practice. So you have to shoehorn archive names behind an artificial # in `SourceX` (because admitting the file name is not always part of the URL and a separate tag is needed is out of the question), you have the way distros have been forced to invent %dist (making Release, in effect, two-tags-in-one), you have the way `%setup` still tries to chainbuild, when maximum rpm, written in *2000*, already document the way people actually use it and expect it to work is multiple `%setup` calls and so on I probably forget half of it.

So it's not surprising people just use `%setup` by rote, just to get past this ordeal as fast as possible, and get to the parts of the spec where they can do things without rpm complaining and trying to impose unintuitive overcomplicated misdesigns on them.

Just provide in rpm a `%setup` alternative that just does what you propose (unpack one archive, without esotheric chaining rules to avoid writing one more extraction command, and with simple ways to query or set buildsubdir that rpm won't stomp on later), and you'll see `%setup` use and misuse drop quickly.

Or, alternatively, fix `%setup` to work how people expect it to work, without the magic they don't expect and don't need.

But having sour grapes about people using `%setup` the way maximum rpm documented 18 *years* ago? And trying to teach them a lesson in the correct way to do things via warnings? That will end badly for everyone involved.


-- 
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/551#issuecomment-424827708
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180926/8305ac63/attachment.html>