Build-essential packages

[Carlos O'Donell]

On 06/11/2015 02:36 AM, Florian Weimer wrote:
> On 05/21/2015 10:11 PM, Jason L Tibbitts III wrote:
> 
>> The BuildRequires section of the guidelines has been revised; the
>> exceptions list is gone.  The release engineering folks are free to
>> define the buildroot and rpm is free to change its dependency list.
>>  * https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2
>>  * https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelines&diff=413629&oldid=409506
>>  * https://fedorahosted.org/fpc/ticket/497
> 
> Can we get a build-essential package instead that requires everything
> that is needed to get a working C and C++ compiler, and run most
> autoconf/automake/libtool-generated scripts (but not the autotools
> themselves)?

Two things:

(1) The C and C++ compilers are special.

They are part of an "implementation" and so it makes sense that they
be provided by something like "gcc" or "gcc-c++" which provide everything
you need to compile a standards conforming C or C++ application.

Therefore programs that are written in C or C++ would BuildRequires: gcc
or BuildRequires: gcc-c++. If in the future we support more than one
system compiler then we may wish to replace them all with more generic
c_lang or c++_lang provides that are satisfied by one or the other
implementations.

(2) The rest of the BuildRequires.

When it comes to autoconf, automake, libtool, sed, awk, grep, I actually
think Fedora needs systemtap or strace based tooling to:

(a) Look at all the tools that were executed in a build.
(b) Recommend a set of BuildRequires: to the user.

That way you can keep your BuildRequires up to date and tweaked relatively
easily. The tooling can be run to output to your koji logs so you can see
exactly what your overall set of BuildRequires are.

Then the developer keeps their list of BuildRequires up to date, small
and relevant.

This helps in distribution bootstrap CI efforts by minimizing BuildRequires,
and helps reduce buildroot sizes and disk usage during builds.

> In my opinion, it is a bad use of developer time to track what programs
> exactly are called from ./configure, and how these programs match
> sed/grep/coreutils.  It would also  give us a central place where we can
> fix breakage due to missing packages in build roots because a
> significant fraction of packages got a build-required package through an
> indirect dependency.

In my opinion this calls for tooling to help developers with BuildRequires.

The corollary being that one might run such tooling over a bootstrap of
the distribution and compare BuildRequires to package spec and see what
differences there are if any. Then with this information you can make an
informed choice about the need for build-essentials.

Otherwise build-essentials will get cargo-culted into every spec file
and we're back to a defined buildroot standard based on build-essentials
which will grow over the years. All the things RCM wanted to avoid.

Cheers,
Carlos.