On Fri, 17 Feb 2012 08:43:19 -0800
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Fri, Feb 17, 2012 at 10:10:48AM -0500, Tom Lane wrote:
> Bill Nottingham <notting(a)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:
>
> > 1. Python
> > 2. Perl
> > 3. 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:
>
> 1. 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.
> 2. 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.