>> >>> > > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
