Re: [gentoo-dev] Open Build Service

[Ian Stakenvicius]

On 14/11/17 02:33 AM, Peter Volkov wrote:
> On Tue, Nov 14, 2017 at 4:47 AM, Samuel Bernardo
> <samuelbernardo.mail@×××××.com <mailto:samuelbernardo.mail@×××××.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.