Re: [gentoo-dev] Binary release of gentoo

[Noah Justin Norris]

compile farm now thats a good one. how many machines would you need to do 
such a task. i have  cable connection here and  i have 10 plus machines and 
when i get dsl at the place i work i could have 300-600 pentuims 

On Thursday 10 April 2003 07:34 pm, Dan Armak wrote:
> On Thursday 10 April 2003 21:50, Matt Thrailkill wrote:
> > Biggest problem I see is putting them up for download.  Making them
>
> shouldn't be that hard, just require ebuild maintainers to submit a binary
> pkg built with emerge -b when they submit their .ebuilds.
>
> Easy for you to say! I and other gentoo devs use 56k dialup, which
> tyipcally sends data at 33.6kbps. Ever tried uploading big stuff at that
> rate (which also blocks your other internet activity)?
>
> Besides building against GRP would mean a) maintaining a grp chroot
> (reasonable) and b) building every package twice - once for myself, once
> for grp. (No ccache because my cflags are different from grp's). So twice
> the build time. Ugh.
>
> The solution for these is a compile farm into which devs can log remotely
> and build packages. Or it could just build them automatically. But all this
> would be is an extended GRP set - I don't see the need for that. GRP for
> 1.4 is already slated to include all of kde and gnome, plus probably some
> of the other heaviest compiles. Other than that, 99% of systems only need a
> smallish amount of smallish apps compiled, you can finish that quite
> quickly even on a slow machine - quicker probably than it'll take you to
> donwload the precompiled GRP.
>
> (BTW with a fast machine and a 56k dialup, many packages probably take
> longer to download precompiled than to compile locally (that's if you
> discount time taken to download the sources though :-) ).
>
> Anyway if this is just an exnteded set of packages for GRP, why is everyone
> talking about it as if it were a radical new feature?
>
> Making grp include all or nearly all the source tree shouldn't be that big
> a problem. After all we already include most of the longest compiles (and
> have openoffice-bin), so we probably already have at least a third of the
> tree as far as compile time goes - and we can generate it for all archs in
> jsut a few days according to the release policy schedule. So if we wanted
> to make a complete GRP we probably could.
>
> Making it always include all new (stable) versions of packages (for all
> archs!) would need a lot of compile power though, or rather it would need a
> dedicated compile server (or piece of a cluster). Well, if you the
> proponents of this idea have such a server handy, you can easily enough set
> it up to do this and tell gentoo users they can get packages from there.
> Adding a feature to emerge that'll make it fetch binary packages from a
> specified server should be easy enough. (Although we need to improve the
> binary package format to make it specify metadata like CFLAGS, arch... I
> don't know if that's been done yet.)
>
> Well all that you can do you have such a server with a good uplink to
> spare. However we of the project (me personally too) don't think that would
> be good use of such a server, because we think the existing GRP is enough
> (it can be expanded in time, but not so radically as you propose, at least
> not right away. And it's not top priority with us.) So we would like to
> respectfully ask you, if you have such a server, to please donate it to the
> project :-)
>
> (Or at least hear our counter proposal of what we'd do with it. There
> are/were plans of a build farm for devs to log on - for testing though more
> than for building binary packages iirc - I don't know what the current
> status is on that.)

-- 
life is linux 
linux is life 

--
gentoo-dev@g.o mailing list