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

[nim-nim]

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180928/9c9f026e/attachment-0001.html>