On 14/11/17 02:33 AM, Peter Volkov wrote: > On Tue, Nov 14, 2017 at 4:47 AM, Samuel Bernardo > <samuelbernardo.m...@gmail.com <mailto:samuelbernardo.m...@gmail.com>> > wrote: > The only feature that would be useful for now is emerge obtaining the > > precompiled binary packages to install in containers/VMs from http > rather than nfs[1]. > > > Samuel, probably I miss something but this should work out of box: > https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host > > Or do you mean something else? >
I would mirror Peter's concern here -- if you use a "build box" system to generate binary packages with FEATURES="buildpkg", then the consumer systems that would use FEATURES="getbinpkg" will fetch the binary packages with the same standard fetch mechanisms as they do for distfiles (http, https, ftp) based on the value of PORTAGE_BINHOST in make.conf. There shouldn't be any need for NFS from the portage (emerge) perspective. To the project in general: You may want to look into the tindeboxing projects for your basis -- I think those might get you closer to a fully automated package building system than working up from catalyst alone. The biggest issue you will have with doing these types of builds, though, is dealing with the various use flag differences that various consumer systems may have. From what little I've played with binary builds, if you want to offer binpkg's for an entire system set you pretty much have to synchronize all use flags across all systems. So a realistic deployment will essentially require (a) adherence to a specific set of static profiles, or (b) a nearly-infinitely-growing number of build profiles that match each permutation of global and per-package use flag settings that your consumers would have.
signature.asc
Description: OpenPGP digital signature
