%autosetup -T -a 0 -a 1 doesn't extract %{S:0}

[ignatenkobrain]

Name:           nipy-data
Version:        0.2
Release:        5%{?dist}
Summary:        Test data and brain templates for nipy

License:        BSD
URL:            http:https://nipy.org/nipy/
Source0:        http:https://nipy.org/data-packages/nipy-data-%{version}.tar.gz
Source1:        http:https://nipy.org/data-packages/nipy-templates-%{version}.tar.gz

BuildArch:      noarch

%description
%{summary}.

%prep
%autosetup -c -T -a 0 -a 1
ls -l
exit 1

shows

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.siRUjA
+ umask 022
+ cd /home/brain/Projects/fedora/rpms/nipy-data
+ cd /home/brain/Projects/fedora/rpms/nipy-data
+ rm -rf nipy-data-0.2
+ /usr/bin/mkdir -p nipy-data-0.2
+ cd nipy-data-0.2
+ /usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-templates-0.2.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ ls -l
total 4
drwxr-xr-x. 3 brain brain 4096 Nov  8  2009 nipy-templates-0.2
+ exit 1

but if you remove -T, then everything behaves as expected.

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.A7UndR
+ umask 022
+ cd /home/brain/Projects/fedora/rpms/nipy-data
+ cd /home/brain/Projects/fedora/rpms/nipy-data
+ rm -rf nipy-data-0.2
+ /usr/bin/mkdir -p nipy-data-0.2
+ cd nipy-data-0.2
+ /usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-data-0.2.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-templates-0.2.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ ls -l
total 8
drwxr-xr-x. 3 brain brain 4096 Aug 18  2009 nipy-data-0.2
drwxr-xr-x. 3 brain brain 4096 Nov  8  2009 nipy-templates-0.2
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.A7UndR (%prep)
    Bad exit status from /var/tmp/rpm-tmp.A7UndR (%prep)

[ignatenkobrain]

@pavlinamv have time to look at this?

[pavlinamv]

rpm behaves correctly. rpm takes into account only the last option '-a number' in the command.

So
%autosetup -c -T -a 0 -a 1
executes only:
/usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-templates-0.2.tar.gz
because
-T disables implicit unpacking of Source0,
-a 0 is skipped because it is not the last -a option,
-a 1 enables unpacking of Source1

%autosetup -c -a 0 -a 1
executes:
/usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-data-0.2.tar.gz
/usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-templates-0.2.tar.gz
because Source0 is implicitly unpacked.
-a 0 is skipped because it is not the last -a option,
-a 1 enables unpacking of Source1

For more details see link:
https://rikers.org/rpmbook/node70.html#SECTION03541400000000000000

[ignatenkobrain]

@pavlinamv but if you use -a1 -a2 -a3, it unpacks all of those sources, why is the -T -a0 is special?

[pavlinamv]

Implicitly (without any option) source0 is unpacked. The -T option disables %setup's normal unpacking of the archive file specified on the source0 line. You can "re-enable"unpacking of the source0 using -a 0 or -b 0.

[ignatenkobrain]

@pavlinamv but this is exactly what this bug is about ;)

-a1 -a2 unpacks both S:1 and S:2, but -T -a0 -a1 unpacks only S:1 (and not S:0).

[pavlinamv]

Om my VM
%autosetup -c -T -a 0 -a 1 .............. unpacks only S1 (-a 1 is the last -a option)
%autosetup -c -a 0 -a 1 .................. unpacks S0 and S1 (because S0 is special and -T is not here, -a 1 is the last -a option),
%autosetup -c -a1 -a 2 ................... unpacks S0 and S2 (because S0 is special and -T is not here, -a 2 is the last -a option),
%autosetup -c -a 0 -a 1 -a 2 -a 3 ... unpacks S0 and S3 (because S0 is special and -T is not here, -a 3 is the last -a option).
Please can you give me a reproducer such that %autosetup -a 1 -a 2 unpacks S1 and S2 (with this exact numbers)?

[pmatilai]

The problem is that unlike %setup, %autosetup is a regular macro and doesn't really support multiple arguments of the same type - they're accepted but with "last one wins"-semantics:

[pmatilai@sopuli ~]$ rpm --eval "%autosetup -N -a 1 -a 2"

%setup -a 2      -q

[pmatilai]

In other words, I failed to consider such a case when adding %autosetup.

The way arguments are presented in the macro language doesn't scale to such usage, I suppose the best we can do is a workaround by passing anything after "--" as-is to %setup which can handle those multiple repeated arguments by its own logic. Ie this would become

%autosetup -c -T -- -a 0 -a 1

It's not nice or pretty but I dont see a whole lot other options.

[jasontibbitts]

What about anything that calls %autosetup? You have to stop somewhere. Better would be to give sufficient expressiveness to the macro language to handle repeated arguments, and perhaps not need magic internal macros at all. Or maybe just add a Lua argument parsing library as standard and convert%autosetup and anything that wants fancier argument processing to Lua.

[pmatilai]

Yeah, and ponies too.

[ascherer]

Has anybody tried to use

%autosetup -c -T -a 0 -N
%autosetup -D -T -a 1 -N
%autosetup -D -T -a 2 -N
%autosetup -D -T -a 3 # adds %%autopatch if necessary

?

Yep, clumsy but workable.

[ascherer]

@ignatenkobrain what exactly are you trying to set up in the BUILD arena? After downloading ca. 80 MB (which most certainly is not a 'minimal' example), I find that the two tarballs contain top-level directories nipy-data-0.2/ and nipy-templates-0.2/ respectively. So, with your example this should result in

nipy-data-0.2/
      nipy-data-0.2/
      nipy-templates-0.2/

where each subdirectory has similar stuff (MANIFEST.in, PKG-INFO, README.txt, and setup.py) and a single sub-subdirectory (data and templates, resp.).

If this really is your goal, then %autosetup -c -a1 does exactly that. (RTFM)

• -c creates the default top-level and cd's into it
• the default source drop is extracted (-T -a 0 is totally redundant and achieves the same effect)
• -a 1 extracts the next tarball

---

However, if you aim for a more compact BUILD stage, I'd suggest to use

%autosetup
tar xzvvf %{S:1} --strip-components=1 --keep-old-files

which results in

nipy-data-0.2/
      data/
      templates/
      MANIFEST.in
      PKG-INFO
      README.txt
      setup.py

(I haven't looked at the four top-level files, of which only one version survives extraction.)

[nim-nim]

BTW
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35

does something similar for %forgesetup

Define an arbitrary number of sources, call %forgesetup -a in %prep, and you're done.

One could probably reuse some of lua suffix handling routines to automate autosetup some more.

I didn't code a %forgeautosetup -a because I couldn't figure how to pass correct patch information for each archive. It would probably need some alternative form of patch naming that associated a patch to a specific archive.

(The PR is working and stable, it's still receiving tweaks when I find things I could do better while coding its counterpart for Go archives, but that's all)

[nim-nim]

The problem is that unlike %setup, %autosetup is a regular macro and doesn't really support multiple arguments of the same type - they're accepted but with "last one wins"-semantics:

That’s a case for #547
And adding lua argparse or something equivalent to rpm by default.

[pmatilai]

Actually this is just a specific case of #546, and thus duplicate.

[akien-mga]

The limitation this imposes on %autosetup -a 1 -a 2 is quite problematic. What's the recommended approach to untar multiple sources? For now I've had to fall back to using %setup in packages which need it.

If multiple definitions of a given flag can't be handled, maybe it would be possible to add support for specifying multiple values for some flags? E.g. %autosetup -a 1,2,3.

(Commenting here instead of #546 because while I agree this would be solved by #546, this specific case is the one most RPM packagers will run into when using %autosetup as recommended by current packaging guidelines.)