[Fedora-packaging] Scripting language dependencies

[Paul Howarth]

On Fri, 17 Feb 2012 08:43:19 -0800
Toshio Kuratomi <a.badger at gmail.com> wrote:

> On Fri, Feb 17, 2012 at 10:10:48AM -0500, Tom Lane wrote:
> > Bill Nottingham <notting at 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.