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

Petr Spacek pspacek at redhat.com
Fri Jan 16 08:35:50 UTC 2015


On 15.1.2015 23:13, Nicolas Chauvet wrote:
> 2015-01-15 20:18 GMT+01:00 Orion Poplawski <orion at cora.nwra.com>:
> 
>> On 01/15/2015 04:20 AM, Ralf Corsepius wrote:
>>> On 01/14/2015 03:10 AM, Orion Poplawski wrote:
>>>> On 01/12/2015 06:08 AM, Vít Ondruch wrote:
>>>>> Dear Fedora developers,
>>>>>
>>>>> I'd like to collect some feedback about the $SUBJECT, i.e. making
>>>>> minimal build root really minimal, explicitly specifying build
>>>>> dependencies, etc.
>>>>>
>>>>
>>>> Would it be technically feasible to have a different buildroot for arch
>>>> and noarch packages?
>>> What would this be useful for?
>>
>> The thought would be that (almost all) noarch packages don't need gcc, so
>> the
>> noarch buildroot could exclude gcc without impacting existing packages.
> 
> 
> I was going to say the same about noarch/arched packages and gcc
> assumption, also that I don't see any "simplification" in hardcoding the
> default compiler everywhere, specially as It probably depends on the build
> target . I remember other distros were using cross-compiler in buildroot
> and that was working pretty fine if the default "compiler" wasn't
> needlessly assumed.
> 
> Another case about the default buildroot is compiler version, one could
> rely on a newer gcc (such as with a gcc5 package) and rebuild any packages
> with this new buildroot environment without tweaking any sources packages.

(I have no releng experience so I can be completely mistaken, please forgive
me :-))

Another advantage could be mass-rebuild simplification. Maybe we could save
machine and man-time by not rebuilding noarch packages because of gcc rebase
or something like that.

Maybe this can be somehow generalized: If we had a database with mapping:
SRPM -> all packages in build root (implicit and explicit BuildRequires)
we could somehow limit mass rebuilds to packages affected by latest changes.

-- 
Petr^2 Spacek


More information about the devel mailing list