#7 Add ____in_spectool define to work around RPM spec misinterpretation?
Closed: Invalid a month ago by tibbs. Opened a year ago by kkleine.

In favor of #6 I'm creating this new issue. Suppose you have a spec file like this:

%global yyyymmdd %{lua: print(os.date("%Y%m%d"))}

Name:    foo
Version: 13.0.0
Release: 1
Summary: Foo
License: Foo

Source0: https://github.com/kwk/llvm-project/releases/download/source-snapshot/llvm-release-%{yyyymmdd}.txt
#%%if ! 0%{?in_spectool}
%global llvm_version %{lua: print(io.lines(rpm.expand("%{SOURCE0}"))())}
%{echo: llvm_version=%{llvm_version}}
#%%endif

%description
My Description

And you process it with spectool, you'll get this error:

$ rm -vf ~/rpmbuild/SOURCES/llvm-release-2021*.txt && spectool -R -g test.spec

[...]
error: lua script failed: [string "<lua>"]:1: cannot open file '/home/kkleine/rpmbuild/SOURCES/llvm-release-20210419.txt' (No such file or directory)
error: test.spec: line 10: Macro %llvm_version failed to expand
[...]

In order to work around this error one can fence the expansion of the llvm_version variable with a check for a define:

%global yyyymmdd %{lua: print(os.date("%Y%m%d"))}

Name:    foo
Version: 13.0.0
Release: 1
Summary: Foo
License: Foo

Source0: https://github.com/kwk/llvm-project/releases/download/source-snapshot/llvm-release-%{yyyymmdd}.txt
%if !0%{?____in_spectool}
%global llvm_version %{lua: print(io.lines(rpm.expand("%{SOURCE0}"))())}
%{echo: llvm_version=%{llvm_version}}
%endif

%description
My Description

Then you can download the source files using this invocation of spectool:

$ rm -vf ~/rpmbuild/SOURCES/llvm-release-2021*.txt && spectool -R -g --define "____in_spectool 1" test.spec
Downloading: https://github.com/kwk/llvm-project/releases/download/source-snapshot/llvm-release-20210419.txt
100% of   7.0 B |######################################################################################################| Elapsed Time: 0:00:00 Time:  0:00:00
Downloaded: llvm-release-20210419.txt

I'm asking if spectool can provide such a define on it's own. Then an RPM spec file can protect itself from being misinterpreted by spectool. I would love to see this change in spectool and not in the invocation of spectool. I hope this makes sense.


Well, part of the point of the spectool rewrite in rpmdevtools v9 is that now we rely on RPM's own parsing of the spec file. So if it's failing in rpmdev-spectool, chances are pretty good that you goofed in the spec file itself.

I don't particularly want to add stuff like this into rpmdev-spectool because it makes it easier for people to do weird things in spec files.

Oh wait, this is a different spectool, whoops. :sweat_smile:

Well, part of the point of the spectool rewrite in rpmdevtools v9 is that now we rely on RPM's own parsing of the spec file. So if it's failing in rpmdev-spectool, chances are pretty good that you goofed in the spec file itself.

Not sure if you mean this version but the error is the same with rpmdev-spectool v1.1.0

I don't particularly want to add stuff like this into rpmdev-spectool because it makes it easier for people to do weird things in spec files.

It's not to weird to consume a file with lua, is it?

Well, part of the point of the spectool rewrite in rpmdevtools v9 is that now we rely on RPM's own parsing of the spec file. So if it's failing in rpmdev-spectool, chances are pretty good that you goofed in the spec file itself.

Not sure if you mean this version but the error is the same with rpmdev-spectool v1.1.0

I don't mean this version. This version works differently from the one in rpmdevtools. I just misread because I'm also subscribed to this project. :sweat_smile:

I second this change. A potential implementation (using the same convention as clang for the macro name) could be:

diff --git a/spectool b/spectool
index 4c6069b..2cc4583 100755
--- a/spectool
+++ b/spectool
@@ -35,7 +35,7 @@ dbprint = None

 USER_AGENT = 'spectool/' + __version__

-DEFINES = collections.OrderedDict()
+DEFINES = collections.OrderedDict(__spectool__=1)

 # Sure wish I had Python 3.5's subprocess.run(), so here's a hacked one.
 class CompletedProcess(object):

This is all pretty confusing to me because I created this package ages ago to house a rewrite of spectool that as far as I know never went anywhere and other rewrites from other people ended up being the ones that were used. If you're having a problem with a version of spectool that's actually in Fedora somewhere, this probably isn't the right place to file a bug.

Metadata Update from @tibbs:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

a month ago

Login to comment on this ticket.

Metadata