On Fri, 17 Feb 2012 08:43:19 -0800 Toshio Kuratomi a.badger@gmail.com wrote:
On Fri, Feb 17, 2012 at 10:10:48AM -0500, Tom Lane wrote:
Bill Nottingham notting@redhat.com writes:
OK, so how about:
Scripting inside of spec files
Inside of a spec file, sometimes it is necessary to call a programming or scripting language during %setup, %build, or %install. In Fedora, spec files may in general only use the following languages for this purpose:
- Python
- Perl
- awk/sed
Also, if your package already BuildRequires a specific scripting language (such as Ruby, or Tcl) as part of its normal compile process, it may also be called from the spec file.
Couple of questions:
- Which of the above alternatives demand a BuildRequires for the
language? (Is BuildRequires the right thing for calls that aren't in %build?)
Technically, only python. For good practice I would say both perl and python. I would never say awk/sed.
Which reminds me... maybe we need to specify gawk rather than awk... if someone wrote something that worked only with mawk we wouldn't like that either.
BuildRequires is correct for %setup, %build, %install, and %check... the sections that are run when building a package. %pre/%post/etc would use a form of Requires([pre,post,etc]): instead as they are run on the end user's system at package install time.
- Can we put even stricter limits on scripting language calls from
macro definitions? As an example, the specfile for python-psycopg2 contains
%{expand: %%define py3ver %(python3 -c 'import sys;print(sys.version[0:3])')}
which I find to be a perpetual annoyance because I don't have python3 installed on my system, and so *any* tool that parses the specfile burps out an error message, for example pretty nearly any fedpkg command
The very general approach of using a scripting language that the package (or a subpackage) is building for seems valid. So I don't think that this should be restricted here.
That macro could be better, though. For instance, if you use this: %{!?py3ver: %global py3ver %(%{__python3} -c 'import sys; print(sys.version[0:3])')}
You won't get the errors that are coming from that %{expand} line.
However, that won't prevent you from having other errors/warnings like this: sh: /usr/bin/python3: No such file or directory
You could get rid of those by using:
%{!?py3ver: %global py3ver %(%{?__python3} -c 'import sys; print(sys.version[0:3])' 2>/dev/null)}
And sometimes you might even prefer:
%{!?py3ver: %global py3ver %(%{?__python3} -c 'import sys; print(sys.version[0:3])' 2>/dev/null || echo 3.0)}
That would give a result that "looked right" in the absence of python3, giving other bits of the spec that depend on that definition a better chance of working as expected.
Without python3 installed, macros in the spec file can't be expanded correctly (because their definitions depend on python3). The spec file is BuildRequireing python3 so it shouldn't be expected that you can operate on the spec file without python3 installed.
I'd prefer to see specs a bit more robust so that for instance you could run "spectool" on them to download upstream sources and then do a mockbuild, which wouldn't require python3 or whatever to be installed on the build host.
Paul.