From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13393 invoked by uid 1002); 10 Apr 2003 19:34:43 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 30015 invoked from network); 10 Apr 2003 19:34:42 -0000 From: Dan Armak Reply-To: danarmak@gentoo.org Organization: Gentoo Technologies, Inc. To: gentoo-dev@gentoo.org Date: Thu, 10 Apr 2003 22:34:23 +0300 User-Agent: KMail/1.5.1 References: <200304100013.30307.gentoo@mchsi.com> <20030410115023.209d65d5.xwred1@xwredwing.net> In-Reply-To: <20030410115023.209d65d5.xwred1@xwredwing.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Adcl+nk9bTH7sEi"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200304102234.24047.danarmak@gentoo.org> Subject: Re: [gentoo-dev] Binary release of gentoo X-Archives-Salt: b5e94f1a-55cf-4587-8a70-b5d2eda8e1b1 X-Archives-Hash: ea13653c7478ba86ea98f94bb9b07c7b --Boundary-02=_Adcl+nk9bTH7sEi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Thursday 10 April 2003 21:50, Matt Thrailkill wrote: > Biggest problem I see is putting them up for download. Making them=20 shouldn't be that hard, just require ebuild maintainers to submit a binary= =20 pkg built with emerge -b when they submit their .ebuilds. Easy for you to say! I and other gentoo devs use 56k dialup, which tyipcall= y=20 sends data at 33.6kbps. Ever tried uploading big stuff at that rate (which= =20 also blocks your other internet activity)? Besides building against GRP would mean a) maintaining a grp chroot=20 (reasonable) and b) building every package twice - once for myself, once fo= r=20 grp. (No ccache because my cflags are different from grp's). So twice the=20 build time. Ugh. The solution for these is a compile farm into which devs can log remotely a= nd=20 build packages. Or it could just build them automatically. But all this wou= ld=20 be is an extended GRP set - I don't see the need for that. GRP for 1.4 is=20 already slated to include all of kde and gnome, plus probably some of the=20 other heaviest compiles. Other than that, 99% of systems only need a smalli= sh=20 amount of smallish apps compiled, you can finish that quite quickly even on= a=20 slow machine - quicker probably than it'll take you to donwload the=20 precompiled GRP. (BTW with a fast machine and a 56k dialup, many packages probably take long= er=20 to download precompiled than to compile locally (that's if you discount tim= e=20 taken to download the sources though :-) ). Anyway if this is just an exnteded set of packages for GRP, why is everyone= =20 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=20 problem. After all we already include most of the longest compiles (and hav= e=20 openoffice-bin), so we probably already have at least a third of the tree a= s=20 far as compile time goes - and we can generate it for all archs in jsut a f= ew=20 days according to the release policy schedule. So if we wanted to make a=20 complete GRP we probably could. Making it always include all new (stable) versions of packages (for all=20 archs!) would need a lot of compile power though, or rather it would need a= =20 dedicated compile server (or piece of a cluster). Well, if you the proponen= ts=20 of this idea have such a server handy, you can easily enough set it up to d= o=20 this and tell gentoo users they can get packages from there. Adding a featu= re=20 to emerge that'll make it fetch binary packages from a specified server=20 should be easy enough. (Although we need to improve the binary package form= at=20 to make it specify metadata like CFLAGS, arch... I don't know if that's bee= n=20 done yet.) Well all that you can do you have such a server with a good uplink to spare= =2E=20 However we of the project (me personally too) don't think that would be goo= d=20 use of such a server, because we think the existing GRP is enough (it can b= e=20 expanded in time, but not so radically as you propose, at least not right=20 away. And it's not top priority with us.) So we would like to respectfully= =20 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/w= ere=20 plans of a build farm for devs to log on - for testing though more than for= =20 building binary packages iirc - I don't know what the current status is on= =20 that.) =2D-=20 Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key --Boundary-02=_Adcl+nk9bTH7sEi Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+lcdAUI2RQ41fiVERAkqFAKCI1nt5SBnk/oVQFaog9Ff6qq4LUwCeI23X tKwe19joYyysmyQd9pHEhpE= =zvB8 -----END PGP SIGNATURE----- --Boundary-02=_Adcl+nk9bTH7sEi--