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

Dennis Gilmore dennis at ausil.us
Sat Jan 17 02:23:10 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Jan 2015 17:18:17 +0100
Miroslav Suchý <msuchy at redhat.com> wrote:

> On 01/14/2015 04:00 PM, Dennis Gilmore wrote:
> >> On 01/13/2015 06:01 PM, Dennis Gilmore wrote:
> >>> > > 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.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUuceOAAoJEH7ltONmPFDRrq8QAIX07Q9MiY0RhXPveO+U48Kx
rPoU9N2Sbyje1pAphkDeTSlRqIJn/cFnHCorVPkbi2GEUbLZ/0bZSVixVr/7aIn0
BymonZJiuc5skQkA0WVOUZyK5O801dOrztzvMUEmTLGG6j5SSjFg3W4yO1Vnn1l3
P6vPnczjGDOn42mDjdKGUVnEifsryFlNIRkQQycaVCmGPh0vkJGX3cYzu6ALUS4F
ejSozB40LG6CMoLHDH4vi8MwLAz6/39siGxD/hkFOpziWSqAcvm6lSTlPREbSpTA
E7gY+FGaT+7jQDSpJViUcfrIAinFlIIab0VUkdI+zd0v7vK+NJBluwfGHBl1817m
IdA6Nz1jXG/5gQqTb8LdefCDuMyFpG1DWuiIF63vSmr83uMZOBSRWTtdS8jcRl39
qylx+CzKL4OAzBOlnSi437bitbyKOSLw2h0qDHiL29LvAsngKegLiXDiTvkGnkXX
zNWUTkaHg+BCg/qzl9Zz3dgEtXOfTHXHKWoRl8L2/i101W4ucgx5ZHQFMydo9jiN
e/e0E/FKqAAq0BbbK7+ltnKrpUeTxuQ74apjLbEAl6XMk9vYKORWxpUkHeGiasPM
EvhOPf5LEi+veCvRPuqzU0jVauJxJeaLY2w0vGkdqfoj1w6fqO6JR63BIv/tXC5A
MaD5XcAcF7a17uQDaQ1s
=4vDY
-----END PGP SIGNATURE-----


More information about the devel mailing list