Remove gcc, gcc-c++ and make from minimal build root

[Vít Ondruch]

Dne 13.1.2015 v 08:12 Ralf Corsepius napsal(a):
> On 01/13/2015 07:12 AM, Stanislav Ochotnicky wrote:
>> On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
>>> Vít Ondruch wrote:
>>>> I'd like to collect some feedback about the $SUBJECT, i.e. making
>>>> minimal build root really minimal, explicitly specifying build
>>>> dependencies, etc.
>>>
>>> -1, all the serious software requires gcc, gcc-c++ and make to build.

I am glad that you consider Ruby from ~66,6 % a serious software, since
it is written in C and uses make. Sadly, it is not written in mixture of
C and C++, otherwise it would reach 100 % seriousness achievement.

On the other hand, you probably don't consider any program/script
written in Ruby as serious, which decreases value/usefulness of Ruby to
zero. Hence your definition of serious software is doubtful.

Of course you can substitute Ruby for Python, Perl, Java ....

>>>
>>>
>>> I actually think that cmake should be added to the minimal build root,
>>> instead of removing stuff. Almost all the packages I work on
>>> BuildRequire
>>> cmake (which also implies that they need make to build, and gcc-c++
>>> is the
>>> typical implementation language).
>>
>> Yes good idea. I worked on Java packages. Let's put Maven in minimal
>> buildroot. I am sure everyone will enjoy it.
>>
>> Sorry for the sarcasm. Couldn't resist :-)
>>
>> Seriously though what's a problem with listing your package's real build
>> requires?
>
> I basically see several issues:
>
> 1. The sheer amount of packages being affect.
>
> Though I also think the ratio of scripted/compiled package has changed
> towards scripted languages, I do not think the number of compiled
> packages has decreased in absolute numbers and still is very high.

So we are even not able to tell how many packages are written in C or
C++ in Fedora, since we do not have the BuildRequires speficied
correctly. Because we have still the false feeling that everything is in
C/C++, we regularly doing mass rebuilds and wasting resources (mass
rebuild has also different advantages, but the rebuild due to rebased
GCC is the major one).

So lets try to find what is written in C/C++ by some different way. Is
that true, that every package in C/C++ compiled using gcc depends on
glibc? Then we can use this query to get the number of packages:

$ repoquery --source --whatrequires 'libc.so.6(GLIBC_2.4)(64bit)' | sort
| uniq | wc -l
2834

But there are different version of source packages, so the actual number
is lower.

I don't know how to determine the packages which are using make, unless
I want to checkout entire dist-git or analyze build logs.

>
> 2. The semantics of such a change.
>
> To me, they are not clear, because having "gcc" or "gcc-c++" in a
> build root covers multiple use-cases.
> For many packages, they just satisfy the need for an arbitrary
> "c"/"c++" compiler, but actually do not mean a strict requirement to
> have "gcc"/"g++". 

This is valid point. If we want to move to different compiler chain one
day, we would probably change the BR's. But:

1) This is not on the table any time soon.
2) It could be done in similar fashion to package renames, e.g. the new
compiler chain would declare the gcc provide.

> Similarly, they may exist packages which actually have dependencies on
> something which currently is being pulled in indirectly through gcc
> (say libgcc), while the package doesn't actually depend on a c-compiler.

That is fine with me. We will add BR the packages need. And you can
never prevent broken BR, since the packages you are building against are
evolving.

>
>
> 3. There likely are many tiny problems under the hood (esp. in
> packages primarily written in scripted languages), such as (yet
> unknown and hidden) conditionally built
> features/sub-components/sub-packages and conditional deps etc.

Definitely, something will bite us. Nobody claims the opposite. Nobody
says its piece of cake, lets do it for F22.

>
>
> I.e. though I am in favor of minimising the buildroots, I don't expect
> removing gcc/g++ will become an easy effort nor should it be taken
> light-heartedly.

I proposed several steps:

1) Update packaging guidelines, get rid of the exceptions (at least the
gcc, gcc-c++ and make), let developers specify these dependencies
explicitly.
2) Update rpmlint to fire warning when suitable
3) Drop the gcc, gcc-c++ and make from minimal build root in F24 timeframe

Of course we can do 1 and 2 and reevaluate 3 anytime in the future.


Vít