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

nim-nim notifications at github.com
Sun Sep 23 12:59:24 UTC 2018


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 builsubdir to the *last* processed archive, and cds to this last archive at the start of build

This has the following deleterious side effects:

1. the packager ends up working in an addon subdirectory, which is utterly confusing, because this is not the subdirectory he cares about most, and will change over time depending on the number of addon archives he adds to his spec

2. you can not do any cleanup of the extracted archives in %prep, that involves things that should end up in the packager main work directory, because this directory does not exist before all archives have been extracted. Instead of the natural:
```specfile
%prep
for each SOURCEX
  %setup
  cd to extracted archive
  archive prep work
done
```
you need to code *two loops*
```specfile
%prep
for each SOURCEX
  %setup
  remember the extracted dir
done ← at this point only builsubdir is set to its definite value
for each extracted dir
  cd extractdir
  do prep work that involves the final workdir
done
```
This is needlessly byzantine, just set `builsubdir` to the first archive subdirectory, so it is garanteed to exist after the first %setup invocation, and packagers get warped to their main project files at the start of %build

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


More information about the Rpm-maint mailing list