With the latest changes to the `%setup` macro this may now be easier and should
be looked at again.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/551#issuecomment-1812148572
You are receiving this because you are subscribed to this
Thanks, I need to investigate if #860 solves the problem for me
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This could potentially be solved by #860 (ie just allow macros to do what they
want with it)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You have chosen rpm spec files and macros for your implementation.
Neither was designed for multiple builds in a single package, nor was rpm for
that matter.
Instead of complaining about rpm deficiencies and quirks, you might wish to
rethink your approach, look at the inputs of archive/patch
> For example, the common case of a single well formed compresset tarball with
> a patch in a spec file is even simpler than your design:
>
> %prep
> %setup
> %patch
And that can be trivialy declined in
```specfile
%prep
%setup -z 0
%patch0
%setup -z 1
%patch1
%setup -z 2
%patch2
```
(of
@nim-nim:
Your "nice properties" arguments are not persuasive.
Point by point:
1. Simple and easy to understand
For example, the common case of a single well formed compresset tarball with a
patch in a spec file is even simpler than your design:
%prep
%setup
%patch
2. It is simple and
> > No it won't, the variable is not really set before %build
>
> NOW we're getting somewhere. %setup parsing certainly defines it, and this
> happens before any shell script is executed, but I see it gets lost somewhere
> in the cracks of %prep parsing. I can take a look at it, all I remember
Oh and BTW, if the reason for wanting to use %setup "at any cost" is that it
knows how to extract tar, zip, ruby gems and whatnot automatically, then *that*
might be another concrete something we could look into, ie add a simpler lower
level %extract or such helper macro/tool that can do what
> No it won't, the variable is not really set before %build
NOW we're getting somewhere. %setup parsing certainly defines it, and this
happens before any shell script is executed, but I see it gets lost somewhere
in the cracks of %prep parsing. I can take a look at it, all I remember
off-hand
RPM has no concept of "chain building": there is only one build in the spec
file, and there is only one SRPM.
Please define whatever terms you choose to make up before using so that others
might understand your complaints.
--
You are receiving this because you are subscribed to this thread.
> @nim-nim, but isn't that just about exactly what %setup by default does?
Not really, since the chainbuilding interferes `%setup` reuse with the next
archive
People just want to align
```specfile
%somesetup -z 1
%somesetup -z 2
%somesetup -z 3
```
Like they align path or source declarations
@n3npq It looks like you are deleting most of your comments after posting them
here. This disrupts the discussion and renders the tickets unusable. Also note
that they are still available in the mailing-list archive and everyone's mail
folder - if you don't want your words to be archived and
First of all, MaximumRPM was written in 1997, not 2000.
Second, the vast majority of packages have no need for a fancier %setup, nor
enhancements like %autosetup. Most software has been distributed on the
Internet as a tarball that can be downloaded, and most packages do not need
anything more
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
Part of the problem is the lengths people go to in order to use %setup for
unpacking sources even when it ends up being counter-beneficial. Just call it
once to setup the main directory and do the rest with tar/unzip/whatever. It's
not like the magic %setup incantation required to unpack dozen
Even simpler -- only one line of code needs to change -- would be to define
_buildsubdir only if it is not already defined.
That might even permit overriding _buildsubdir to be set from the spec file, or
-- with Yet Another POPT alias -- from the rpmbuild command line.
And of course %setup
FWIW, here is an implementation that would permit first rather than last
definition of %_buildsubdir to be used under user control.
RPM5 permits read only macros which -- when set -- prevent a macro value from
being changed.
The syntax prefixes a macro name with a '.' in order to set (actually
You are absolutely correct that %setup from time immemorial has been overly
complicated, non-intuitive, and *documented*.
Expecting users to change their behavior 20y later is a political task, better
left to distro packaging committees and package reviews: %setup does what
%setup does.
I don't doubt that's what the setup authors intended, but really, it's overly
clever for human beings, that like their commands simple and easy to remember,
it's overly clever for scripts, that like to loop over the same command not
compute complex lists of arguments, it's overly clever for
You're supposed to use `%setup` once, and tell it how many archives it needs to
extract before it it should change into the workdir.
For example: `%setup -q -b 3` tells it to unpack `Source0`, `Source1`,
`Source2`, and `Source3` before changing into the `%name-%version` workdir. If
you want
I believe that's what the `-n` option of `%setup` is for. You can (or have to)
set/repeat the desired `%buildsubdir` on every invocation of `%setup`. (IIRC,
multiple `%setup`s are deemed esoteric/byzantine anyway.)
--
You are receiving this because you are subscribed to this thread.
Reply to
The %setup macro-in-c was never intended to be used multiple times: see the
shell code generated, and look at the needless unnecessary commands generated
if/when %setup is used multiple times.
You are likely better off (for whatever you are attempting) using %setup once
to set %_buildsubdir,
rpm convention is to put the main archive in SOURCE0 and ancilliary sources in
SOURCEX
(this way SOURCE0 is sure to exist and be stable, and can be aliased to SOURCE,
while the number of addons and their index can vary over a package time)
However rpm does not respect its own convention, sets
23 matches
Mail list logo
