Re: [gentoo-dev] Binary release of gentoo

[Dan Armak]

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.)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key