On Fri, 17 Feb 2012 08:43:19 -0800
Toshio Kuratomi <a.badger@xxxxxxxxx> wrote:
> On Fri, Feb 17, 2012 at 10:10:48AM -0500, Tom Lane wrote:
> > Bill Nottingham <notting@xxxxxxxxxx> 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.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
