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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
