> > 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 is that %prep parsing is entirely different from the rest of the
> build-sections.
>
> However I still don't see the big problem here. %buildsubdir is not some
> magic random value calculated by rpm, it's always %{name}-%{version}, or
> literally whatever you pass to %setup with -n argument. It's also the
> directory you'll find yourself in the shell, so derivable from "basename
> ${PWD}" inside %prep.
The packaging pattern is
```specfile
Source0: main-archive
Source1: addon1
Source2: addon2
Source3: addon3
[...]
%prep
%setupsomething -z 0 (main archive)
%setupsomething -z 1 (addon 1)
%setupsomething -z 2 (addon 2)
%setupsomething -z 3 (addon 3
```
It has the nice properties that:
1. it is simple and easy to understand
2. it is simple and easy to explain
3. it is patch and preparation friendly (just put the `%patch` or any other
archive fixup directive after the corresponding `%setupsomething` line)
4. it is spec-maintenance friendly (want to remove a particular addon ? just
remove the corresponding lines, you end with a simple diff with added and
removed lines, without side-effects on other lines – or changed lines if you
prefer to call it that way)
And I used `-z` instead of the horrible `-a -b -T -n` mix that no one
understands at first and is only there to permit chaining and to avoid
standardizing a way to specify the topdir upstream uses with its archives, and
the topdir the packager wishes to generate (if uptream is topdir-less).
That's the packaging pattern Maximum rpm already documented in the last
century, and having spent some months writing macros which are intended to be
used in `%prep`, and tried to document them to others, I understand 100% why
the Maximum rpm authors chose to document it that way (and I agree with them).
Maximum rpm is the main vulgarisation document that attemps to explain how to
use `%setup` with multiple archives. I'd say it succeeds poorly, in large part
due to `%setup` quirks, but at least it tries.
Now, as Neal explains, those quirks are largely due to the historical `%setup`
chaining design. But almost nobody uses `%setup` that way. First, it is not
documented in any specfile writing vulgarization document. And second, even it
it *was* documented, it does not have the nice packager-friendly properties of
the no-chaining approach which *is* documented in Maximum rpm.
However, even even if you use `%setup` without chaining, you still get bitten
by the chaining design.
Because `%setup` assumes you will use it in one call, it makes no provision to
set `%{buildsubdir}` cleanly. `%{buildsubdir}` is whatever you passed `%setup`
with -n, why you use several `%setup` calls, how weird, why are you doing that?
(I've already explained why).
So packagers mostly accept this is dark rpm vodoo and that rpm will chdir to
the last addon directory in `%build` (which is definitively *not* their main
work directory).
This RFE is about setting `%{buildsubdir}` by default to something sensible:
the extraction directory of the `Source0` archive, which will almost always be
the main archive processed by the spec, due to historical conventions.
Alternatively, just making it possible to override in `%prep` the mess `%setup`
makes of this all, works for me too.
I'm *definitely* not interested in anything that would be equivalent to
```specfile
%prep
%myprepmacro
%build
%fixmyprep ← workaround %{buildsubdir} selection in %prep
```
--
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-425398717_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
