-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Make %setup
work with archives regardless of inner structure
#2664
Comments
%setup
work with archives regardless of inner structure%setup
work with archives regardless of inner structure
Right, this closely relates to #2078 as well. Libarchive is currently an optional dependency, but a hard dep wouldn't be the end of the world. |
We could make |
That would bring it in line with the way |
@Conan-Kudo how libarchive can help in detect if the archive needs to be extracted as is or in a subdirectory? |
I believe we have to inspect it to check. |
In simple words the logic will be: if the archive contains a single entry extract it as is, otherwise create an entry like $name-$version? |
Not quite. If it contains a single entry, strip it. Always create the directory |
I have a draft change in https://github.com/teknoraver/rpm/tree/libarchive2 Most of the work needed to be done in
|
Done in #2859 |
Oh, yup, this can be closed now. Thanks again! |
In a conversation in
#devel:fedoraproject.org
with @penguinpee, I realized that there's a potential quality of life improvement we could look into making around%setup
: Making it so we don't ever need to use-n
.It started with asking about how to pass in
--strip-components=1
to%setup
, and I realized something: now that libarchive exists, it would be possible for us to have a universal unarchiver program with RPM that can give us the ability to automatically handle extracting archives properly, regardless of what the name of the top level directory is or whether there is even one at all.For some prior art, Debian's packaging tooling can do this, and it uses that to 1) extract the tarball into a
name-version
directory, and 2) blow awaydebian
directory of an upstream tarball if it exists so its own version can be unpacked in-tree.Obviously, we don't need to do the second thing, but the first thing would be extremely useful. Note that because of compatibility concerns, we'd probably want this new behavior in a new macro.
The text was updated successfully, but these errors were encountered: