Removing perl from build root

Thursday, 31 March 2016

Fedora's minimal build root contains perl. There is a reasonable request
<https://bugzilla.redhat.com/show_bug.cgi?id=1158860> to
remove the perl in order to minimize the build root. (The x86_64 F25 build
root occupies 527 MB now, 20 MB of that are perl packages.)

The reason why perl is there is the rpm-build package. The Requires dependency
tree looks like:

rpm-build
    perl-generators
        perl(:MODULE_COMPAT_5.22.1)
        perl(Fedora::VSP)
        perl
            perl-macros
    system-rpm-config   (a Provide)
        redhat-rpm-config
            perl-srpm-macros

While perl-srpm-macros's presence is intended, perl-generators' presence is
unwanted.

On technical level, the reason is the rpm-build binary package requires
perl-generators explicitely. It's there for backward compatibility. Simply
removing the dependency removes perl from minimal build root.

But the compatibility is important. Without perl-generators in a build root no
Perl dependencies are generated into binary packages. To fix it, every Perl
package must build-require perl-generators.

This change will go through a Fedora system wide change process and Perl
packaging guidelines update. I'd like to implement it in Fedora 25.

Few weeks ago, me, Contyk and Jitka were thinking about the new packaging
guidelines. We concluded that the guidelines should contain only the necessary
minimum and best practices should be documented on freely updatable wiki page.

We found these interesting packages:

perl-generators     requires perl and some other modules
perl                /usr/bin/perl
perl-libs           libperl.so and essencial modules and perl(:MODULE_COMPAT_)
perl-devel          requires gcc for header files
perl-macros         requires perl(:MODULE_COMPAT_) now
perl-srpm-macros    no dependencies

Guidelines should describe that:

(1) You must build-require perl-generators if you install a Perl code to
ensure run-time depencies are automatically generated.

Then there are other rules that are actually implied by the generic guidelines
(require everything what you use) that could or could not go the the
guidelines as:

(2) You must build-require perl-macros if you use a macro provided by them.

(3) You must build-require perl if you execute the perl interpreter at
build-time.

(4) You must build-require perl-devel if you build XS code.

Questionable are %__perl and %perl_vendorlib-like macros, what macros are
provided by perl-srpm-macros and what macros are provided by perl-srpm-macros.

%__perl and %perl_vendorlib macros come from rpm. Former rpm Fedora
maintainer claimed he want to own the macros forever. But the truth is they
do not work without installed perl. And rpm does not require perl.

The division between perl-macros and perl-srpm-macros is, in my vision,
defined by requirement on perl interpreter. perl-srpm-macros will never
require perl. The question is where to put all the neat macros I published on
this mailing list in the previous month (the version normalization etc.).

The version normalization will go into perl-srpm-macros as it it necessary for
creating source RPM packages. If we implement normalization in F25, we should
mention it in the guidelines:

(5) Perl module versions must be normalized with %perl_v macro
like "BuildRequires: perl(Module) >= %{perl_v 1.2}".

We could also make the guidelines less how-to and more descriptive by
explaining the normalization algorithm and allowing packagers to do the
normalization manually (like listing run-time dependencies manually). But I'm
not sure if it were helpful.

Back to the build-requires. I can add "BuildRequires: perl-generators" into
all spec files that run-requires or provides perl(). This can be performed
even without mass rebuild.

I'd like to hear if this approach (adding "BuildRequires: perl-generators"
everywhere) is fine. For example, a spec file for architecture specific
package would need:

BuildRequires: perl             for "perl Makefile.PL"
BuildRequires: perl-devel       for building XS code
BuildRequires: perl-generators  for generating dependencies
BuildRequires: perl-macros      for %?perl_default_filter

It looks like a lot of copy and paste code. On the other hand, It allows to
write spec files that do not need all the Perl packaging features. For
example, an package that only installs a perl script can be happy with only:

BuildRequires: perl-generators  for generating dependencies

-- Petr

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005