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

[Peter Robinson]

>> >>> > > that all being said. koji doesn't use any caching and will
>> >>> > > not use the lvm plugin. we make every buildroot from scratch
>> >>> > > using a fully clean environment to help with ensuring
>> >>> > > reproducability.
>> >> >
>> >> > You can cache and still preserve reproducability. What I'm
>> >> > planning for Copr is to do (every week/month) for chroot in
>> >> > fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot
>> >> >   done
>> >> > take snapshot of that. I plan to do that on VM level.
>> >> > And when new task come, I will just restore from that snapshot.
>> >> > And mock will start with already populated cache. So I will have
>> >> > better caching and yet reproducability.
>> > you really can't.  you would need to make a new cache any time one
>> > of the packages in the minimal buildroot changes.
>>
>> That is why mock run 'yum update' on minimal buildroot before
>> proceeding further. So if one package in buildroot changes, you will
>> just download and install just that one package and all other comes
>> from cache.
>
> That invalidates being able to reproduce the build root exactly. as you
> would need to know and reproduce the package update. This is something
> that has undergone a lot of thought and consideration and there is very
> very good reasons things are the way they are. as i showed elsewhere in
> this thread most repos are used only once or twice at most on any given
> host.

The only way you could cache a base build root effectively is if you
track the packages and NVRs and when one of them bump you regenerate
the buildroot, likely pausing all builds until a new one is there.
there's likely not that much churn in the packages contained in the
root buildroot (you'd want to make sure you had everything for
building .src.rpms too) and in some cases you could likely get days on
the same image without having to rebuild it, other days you might have
to do it a few times a time.

Whether the effort to implement out weights the effort remains to be
seen. I think, given the low IOPs on the builds with an underlying COP
image it might well give a reasonable reduction in building especially
during mass rebuilds where the builders are very active and as it's in
a side tag the new build root packages don't end up in the build root
until tagged. Using fedmsg it's likely not hard either to monitor a
package subset for changes and regen the image.

Peter