[Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

nim-nim notifications at github.com
Mon Dec 11 09:39:28 UTC 2017


Well, the macro I'm working on for Fedora already pretty much does "builds on a public branch, downloaded through https,  on a tagged/documented check-in located in an upstream VCS repository"

It does not use a magic URL but clear commit/tag variables like other git-oriented tools like godep do (I don't want to be in the business of creating magic urls only to parse them, separate fields are much better)

It does not allow builds from branches as some tools because the tip of a branch moves so that's not reproducible. The packager has to specify a tag or commit hash.

It uses plain https not ssh as Internet ssh does not work in restricted networks, and relies on the public scm autoarchives not the scm itself (that would be trickier to maintain and autoarchives are cleaner)

It is already as safe as it can be, except for %{dist} and %setup munging.

Making %{dist} safe is just a matter of adding a %{?distprefix} placeholder to the default Fedora definition

Making %setup safe is a little more tricky (but that only matters for the few packages that need to call %setup several times in a row, which is already deep black magic for most packagers).

Since the automation macro already knows on what file it needs to apply specific %setup arguments (it's %{_sourcedir}/%{archivename}.%{archiveext}) maybe it's possible to redefine %setup just in this case? Where do %setup store its file argument? Is it possible to do something like:

%global setup() {
%if ??? == "%{_sourcedir}/%{archivename}.%{archiveext}"
   %%setup %{?_setup_args}
%else
 %%setup
%end
}

-- 
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/368#issuecomment-350671196
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20171211/9492a5d7/attachment-0001.html>


More information about the Rpm-maint mailing list