Hello,
Warning: This e-mail is long and proposes changes in Perl packaging.
The Problem
===========
I decided to tackle the long standing issue with Perl versions that are not
compatible with RPM.
For example, you have a module or distribution in version 1.2, then 1.21, then
1.3. In addition, Perl 5 mixes fraction (1.200300) and dotted (1.2.3 or
v1.2.3) versions. In addition to addition, there can be underscores for
unstable releases that everybody explains differently (pre-release,
post-release, ignorance). The difficulty comes when writing these "numbers"
into spec files as dependencies or tracking monotonic upgrade-path.
Preparation
===========
You could notice Fedora possess perl-Fedora-VSP and fvsp packages. Both of
them implement version normalization so that Perl version input is converted
into RPM-compatible output.
perl-Fedora-VSP is a pure-perl implementation used in dependency generators
for exporting "Requires: perl(:VERSION) >= 5.22.1" from "use 5.022001". That
fixed the wrong "1:perl >= 5.02201" format.
fvsp is a native C code. A fvsp(1) tool and vsp(3) function in libfvsp
library. It's not used now, but it's inteded for SRPM macros living in minimal
build root (that will miss perl in the future).
The normalization follows the Perl's version->parse->normalize rules and then
it removes redundand zeros for brevity:
$ fvsp 1.2
1.200
$ fvsp 1.23
1.230
$ fvsp 1.2345
1.234.500
$ fvsp 1.2.3
1.2.3
$ fvsp v1.2.3
1.2.3
$ fvsp v1.2
1.2
A text after an underscore is ignored currently.
Minimal Spec File Changes
=========================
How a minimal spec file change could look like:
BuildRequires: perl(File::Spec) >= %{perl_v 1.2}
The %perl_v macro would do the trick.
More Changes Possible
=====================
But as you can see this notation is actually longer, so I immediatelly tried
something more useful:
BuildRequires: %perl_d File::Spec 1.2
This one is shorter, it hides the Perl specifics and you don't have to write
the omnipresent relation operator ">=". (You can still supply it like in
"Conflicts: %perl_d File::Spec < 1.2".)
Looking at other parts of the spec file, you can see the %prep, %build,
%install, %check sections are all the same. They only depend on Makefile.PL or
Build.PL build script. Also all CPAN packages have very similar Name, Source,
and URL tags. Therefore I wrote more macros and then showed a rewritten
perl-aliased.spec file to my coworker. He said: "All the BuildRequires and
Requires words is a boiler plate code. Could you make it shorter?" I replied
that it's not possible because of multi-line macro arguments, but then
I discovered that macros written in Lua can handle multi-line macros to some
extent, so I come up with this:
====START====
%perl_macros 1
%perl_cpan_package ETHER aliased 0.34
Release: 4%{?dist}
Summary: Use shorter versions of class names
License: GPL+ or Artistic
BuildArch: noarch
# Module Build
%{perl_build_requires \
Module::Build::Tiny 0.039
}
# Module Runtime
%{perl_build_requires \
Carp
Exporter
strict
warnings
}
# Test Suite
%{perl_build_requires \
B
CPAN::Meta 2.120900
File::Spec
lib
Test::More 0.88
}
# Runtime
Requires: %perl_d_compat
%{perl_requires \
Carp
}
%description
aliased is simple in concept but is a rather handy module. It loads the
class you specify and exports into your namespace a subroutine that returns
the class name. You can explicitly alias the class to another name or, if
you prefer, you can do so implicitly. In the latter case, the name of the
subroutine is the last part of the class name.
%prep
%perl_prep_cpan
%build
%perl_build
%install
%perl_install
%check
%perl_check
%files
%license LICENSE
%doc Changes CONTRIBUTING README
%{perl_vendorlib}/aliased.pm
%{_mandir}/man3/aliased.3*
%changelog
====END====
There are some issues: You have to write something after the
%perl_build_requires macro name (a plain space character is enough, but
backslash emphases it), you cannot put comments into into %perl_build_requires
argments (well you could, but the Lua code would have to handle it and I worry
I would step on undefined behavior in the RPM), you have to declare that a
package is noarch manully, you still have write %files section etc.
Maybe you are curious what the "%perl_macros 1" is. First it is necessary for
%perl_build_requires and %perl_requires to work (it allows them to share
the multi-line statement parser). Second it allows the spec file to declare
expected macros API on one hand and it allows to introduce incompatible
changes in the macro files on the other hand. The macro files can support more
API's at the same time.
Proof of Concept
================
You can find the macros implementation on
<https://ppisar.fedorapeople.org/perlmacros2/>, especially in the
src/macros.perl2 file. Please note that the version normalization is not
enabled there. (Though you can enable it by swapping %perl_v definition.) Also
note that dependency generators have not yet been enhanced to support the
normalization.
Compatibility
=============
Introducing this normalization requires changing both build-requires and
run-requires at the same time (you cannot provide "perl(Foo) = 1.2" and
build-require "perl(Foo) >= 1.200"), the normalization would be enabled at one
of the Perl mass rebuilds. But we could start using the macros gradually
even before the big switch. For those who would not find all the macros
appealing and would not convert their spec files, we could just wrap the
version strings in BuildRequire and Requires statements into %perl_v macro
automatically by a script.
We also have to think on people, who share spec files among more Fedora
braches. There should not be a problem to push the macro files into all
Fedoras with disabled version normalization.
Another story is EPEL. EPEL cannot replace RHEL packages, but there were
attemps to augment minimal build root package group (which broke software
collections) with additional macro files. So even here it would be possible.
Actually I think that the macro files could provide different implementations
for different EPELs, so that packages could share spec file between Fedora and
EPEL without thinking on all the specifics (like cleaning build root), so it
could be win for all the parties.
I will not hide it---it would also allow alternative implementation for
software collections. It could be possible the import the spec files into
software collections that people want into their COPR or CentOS SIG
repositories.
In the long term, it could provide common base for Perl 6 packages (there are
about 500 upstream Perl 6 distributions, Fedora lacks them all.)
If we decide to normalize package version, we should to enable the
normalization also in the Relase Monitoring service (or new-hottness bot that
is specific to Fedora). There should no be problem to write a simple Python
wrapper around libfvsp and inject it into there.
Build-requires in Build Root without Perl
=========================================
Last question is what package to put the macro files into. What package should
all the Perl spec files build- or run-require? Especially with the advent of
build root without perl interpreter. If we design it properly, we could achieve
it.
Questions
=========
What are your opinions? Do you like the macros? What packages should
(build-)require spec files? Should we handle noarch spec files specially (they
do not need GCC and perl-devel (although ExtUtils::CBuilder required by
ExtUtils::MakeMaker and Module::Build needs them now).
-- Petr
Attachment:
signature.asc
Description: PGP signature
-- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
