[gentoo-dev] Binary release of gentoo

[gentoo-dev] Binary release of gentoo

[Noah Justin Norris]

	Is there any interest to start a binary release of gentoo with precompiled 
binaries. Im talking the entire source tree i know many people that would 
switch to gentoo if they would not have to compile every thing from source .  
not everyone has the fastest computer out there.

	I would be internested in helping work on a binary port of gentoo. I know 
there would be some issues with having a binary port
	1. use settings  ( maybe have 2 versions of apps one clean andone loaded ie 
kde and gnome support)
	2. cflags  (maybe support multible processors i586 i686 pentuim3 pentuim4 
etc)
	I believe there will be others . i have alot of computers and Im willing to 
help out sence and I have lots of free time
	 I know this is possible though I have built packages on one machine and 
installed them on other slower machines.
	
	Note > im not talking about a grp like install thats on a cd , but as a new 
edition to the portage ebuild system as a whole  IE: setting in make.conf 
makes emerge get binarys .


-- 
life is linux 
linux is life 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[leahcim]

On Thu, Apr 10, 2003 at 12:13:30AM +0000, Noah Justin Norris wrote:
> 	Is there any interest to start a binary release of gentoo with precompiled 
> binaries. Im talking the entire source tree i know many people that would 
> switch to gentoo if they would not have to compile every thing from source .  
> not everyone has the fastest computer out there.

I thought it was called Debian? ;o)

Or perhaps, "I'd eat meat, if only it were vegetarian"

Seriously though, I don't see the point, unless you want to sell more T-Shirts, there
are a plethora of good binary distributions of linux out there already and all the downsides you list
are what, imo, define Gentoo.

I'd prefer to see gentoo improved as a source-based distribution

-- 
Michael.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Robert Cole]

On Wednesday 09 April 2003 11:28 pm, leahcim@ntlworld.com wrote:
> On Thu, Apr 10, 2003 at 12:13:30AM +0000, Noah Justin Norris wrote:
> > 	Is there any interest to start a binary release of gentoo with
> > precompiled binaries. Im talking the entire source tree i know many
> > people that would switch to gentoo if they would not have to compile
> > every thing from source . not everyone has the fastest computer out
> > there.
>
> I thought it was called Debian? ;o)
>
> Or perhaps, "I'd eat meat, if only it were vegetarian"
>
> Seriously though, I don't see the point, unless you want to sell more
> T-Shirts, there are a plethora of good binary distributions of linux out
> there already and all the downsides you list are what, imo, define Gentoo.
>
> I'd prefer to see gentoo improved as a source-based distribution

Ditto. There is no point to a binary version of Gentoo. If you want that then 
as Michael said just use Debian.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

begin  quote
On Thu, 10 Apr 2003 00:13:30 +0000
Noah Justin Norris <gentoo@mchsi.com> wrote:

> 	Is there any interest to start a binary release of gentoo with
> 	precompiled 
> binaries. Im talking the entire source tree i know many people that
> would switch to gentoo if they would not have to compile every thing
> from source .  not everyone has the fastest computer out there.


Well, thats one thing thats an interesting idea, another would be to
track our "stable" tree and keep updating the system of GRP binaries to
provide for this.. do note that this means that a system cannot be used
for testing things in a "normal" way (installing odd things that might
be dependencies or not)


To do the whole tree as binary is an impossibility, if nothing else so
for license issues.  But continuously providing it could be a welcome
service.

I know I'd welcome it, as a far simpler way of installing and keeping my
celeron running..    But I think it'd require some more portage hacking
to "make it work", at least the following.

a) package signing
b) configured default binary locations
c) binary-vs-source preference


to do more than one set of USE flags would be overkill imo, and harder
to implement in "true" form.


//Spider


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Dylan Carlson]

On Wednesday 09 April 2003 08:13 pm, Noah Justin Norris wrote:
> Is there any interest to start a binary release of gentoo with
> precompiled binaries. Im talking the entire source tree i know many
> people that would switch to gentoo if they would not have to compile
> every thing from source . not everyone has the fastest computer out
> there.

A "binary release of Gentoo" is out of scope for what Gentoo is trying to 
provide.  We are primarily a source-based distribution, and that's where 
our priorities are set.  Compiling the OS from scratch is not for 
everyone, which we recognize and that's fine ...

There are some packages which make sense to have prebuilt binary options, 
namely Java classes... and large packages which strip CFLAGS at compile 
time, or ones that otherwise don't have any advantage of being compiled 
from source.  We would be very selective of the packages which actually 
use this feature, as we are about -bin packages currently.

The topic of source-or-binary ebuilds (user selectable) is actively being 
debated in -core.   Several options are being discussed as to what angle 
we might pursue.  The aim is an appropriate solution to allow for _some_ 
situations where binaries can be installed without cluttering the portage 
tree with -bin directories.   Currently on the table for review is adding 
a prebuilt USE flag.  Some are for it, some are against it.  I'm sure 
you'll hear about it when/if anything gets decided.

[...]

My general stance is that if someone wants a full binary OS release, they 
should pursue something like Debian, Slackware, et al.  That's their core 
competency... ours is building from source.  There's no right or wrong 
either way, it just depends on what you're after.

Cheers,
Dylan Carlson

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
Key fingerprint = 3AEA DE38 FE42 15A6 C0E2 730E 3D04 BCC1 708E 165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Cedric Veilleux]

We would need portage to generate packages with an additional "manifest" file 
in it or in a package format that could hold meta-information in some way 
such as:

USE flags enabled in this package (only the ones relevant to the particuliar 
package)

Portage's PROFILE (default-x86-1.4 for example)

CHOST / CFLAGS used to compile the package, if relevant.


Then a binary enabled portage would contact a master server and ask for a 
binary package compiled with the right combination of USE flags, profile and 
CHOST and if it exists download it and install it, and if it does not compile 
it from the sources..



Cedric





Le 10 Avril 2003 03:27, Spider a écrit :
> begin  quote
> On Thu, 10 Apr 2003 00:13:30 +0000
>
> Noah Justin Norris <gentoo@mchsi.com> wrote:
> > 	Is there any interest to start a binary release of gentoo with
> > 	precompiled
> > binaries. Im talking the entire source tree i know many people that
> > would switch to gentoo if they would not have to compile every thing
> > from source .  not everyone has the fastest computer out there.
>
> Well, thats one thing thats an interesting idea, another would be to
> track our "stable" tree and keep updating the system of GRP binaries to
> provide for this.. do note that this means that a system cannot be used
> for testing things in a "normal" way (installing odd things that might
> be dependencies or not)
>
>
> To do the whole tree as binary is an impossibility, if nothing else so
> for license issues.  But continuously providing it could be a welcome
> service.
>
> I know I'd welcome it, as a far simpler way of installing and keeping my
> celeron running..    But I think it'd require some more portage hacking
> to "make it work", at least the following.
>
> a) package signing
> b) configured default binary locations
> c) binary-vs-source preference
>
>
> to do more than one set of USE flags would be overkill imo, and harder
> to implement in "true" form.
>
>
> //Spider


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Cedric Veilleux]

> > I thought it was called Debian? ;o)
> >
> > Or perhaps, "I'd eat meat, if only it were vegetarian"
> >
> > Seriously though, I don't see the point, unless you want to sell more
> > T-Shirts, there are a plethora of good binary distributions of linux out
> > there already and all the downsides you list are what, imo, define
> > Gentoo.
> >
> > I'd prefer to see gentoo improved as a source-based distribution
>
> Ditto. There is no point to a binary version of Gentoo. If you want that
> then as Michael said just use Debian.


I don't agree. Gentoo already supports binary packages anyways (emerge -b / 
emerge -k). We're only talking about improving it AFAIK.. What's wrong with 
improving some features of portage if it's possible and if it won't hurt 
anyone?



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Jon Portnoy]

On Thu, Apr 10, 2003 at 04:29:00AM -0400, Cedric Veilleux wrote:
> > > I thought it was called Debian? ;o)
> > >
> > > Or perhaps, "I'd eat meat, if only it were vegetarian"
> > >
> > > Seriously though, I don't see the point, unless you want to sell more
> > > T-Shirts, there are a plethora of good binary distributions of linux out
> > > there already and all the downsides you list are what, imo, define
> > > Gentoo.
> > >
> > > I'd prefer to see gentoo improved as a source-based distribution
> >
> > Ditto. There is no point to a binary version of Gentoo. If you want that
> > then as Michael said just use Debian.
> 
> 
> I don't agree. Gentoo already supports binary packages anyways (emerge -b / 
> emerge -k). We're only talking about improving it AFAIK.. What's wrong with 
> improving some features of portage if it's possible and if it won't hurt 
> anyone?
> 

It's not a question of improving it so much as the distribution 
resources required.

I'm not sure you understand the full extent of the problems with 
distributing binary packaging. The short story is:
Besides loss of flexibility, it's a QA nightmare. It also requires a 
massive infrastructure behind it in terms of putting binary packages 
online for people to download. We don't have space on our mirrors, we're 
not very likely to host something like that - the resources just aren't 
there, frankly, and it doesn't seem very productive for us to dedicate 
those resources to binary distribution when we're a source-based 
distribution...

If someone wanted to do something like this independently, I think that 
would be an excellent resource to a lot of people. However, you need to 
consider the full implications - it's not as simple as it seems on the 
surface...

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

begin  quote
On Thu, 10 Apr 2003 04:13:03 -0400
Cedric Veilleux <cedric@neopeak.com> wrote:

> USE flags enabled in this package (only the ones relevant to the
> particuliar package)

already there, tagged at the end of a .tbz2

<cut> 

> Then a binary enabled portage would contact a master server and ask
> for a binary package compiled with the right combination of USE flags,
> profile and CHOST and if it exists download it and install it, and if
> it does not compile it from the sources..

unfortunately this requires a loot of computing and storage on the
server, as well as bandwidth.   That why I suggested a set of simple
defaults, people who go beyond that, go for source.   We really 
shouldnt spend the energy on "fixing" another set of binary package
management when others have done that for us already. (dpkg, rpm, slack,
bsd)

The GRP are a nice step,  and works well, if we could make it a bit more
usable than current.  I dont advocate going for a lot of hoops and
developertime to make a binary distro as smooth as Gentoo is from
source, since it wouldnt ever be maintained in the same way.   I do
however advocate that GRP become easier to use by default. 


//Spider




-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[leahcim]

On Thu, Apr 10, 2003 at 04:29:00AM -0400, Cedric Veilleux wrote:
> I don't agree. Gentoo already supports binary packages anyways (emerge -b / 
> emerge -k).

Yes, but there's also a good reason why --buildpkgonly needs you to have the
dependancies already :o)

I can build packages here and they'll be useful for me. Given the options I've
set, my packages may be good for a set of people.

The set of people my packages will work for is big but that's because I've not
got a slow machine :o) The number of folk that have the same flags is like

I'd have said a distcc / ccache compile farm that builds by request and caches
packages based on USE/CFLAG etc and dependancy USE/CFLAG is a great sounding
idea.

You wouldn't need to change gentoo, just make it web based as proof of concept.

I bet once you try to scale it, it'll be quicker to build what you want on
a celery[0], and that the faster athlon-xp/p4 systems would get the best benefit.
Unless you drop them.

[0] the criteria being that you want a substantially different system from
using stock Debian + a few source compiles like your own kernel. Highly
optimised. You don't need to convince anyone that you can create a "take it or
leave it" binary distribution that runs on slower machines, you need to show
that you can build and distribute a gentoo system giving the celery owner the
same choices as though they had used source - otherwise you haven't improved
anything, imo.

-- 
Michael.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Henti Smith]

Hi all 

I'm coming in a little late on this discussion .. but here a are a few suggestions ... 

Compile flags: 

people that want massive of fine tuning of compile flags for apss will more likely compile their own software, so I thinks it's safe to work only with arch settings.
if you want the latest binary for mutt running on 486 you need file

mutt-1.5.4.486.tar.gz

for pentium 

mutt-1.5.4.586.tar.gz 

etc etc .. 

this is logical .. and workable.

USE flags.

This is a lot more tricky as use flags will effect alot of applications.

I use vpopmail but without mysql ... 

This makes things alot more difficalt. using a default set of USE can cause problems and setups that people do not want, another way is using a meta system for chacking your USE settings against the USE settings used to compile the binary .. but that opens up many many "variations" on the binary systems and makes "maintance" hell, 

as to hosting the binaries ... maybe looking at something like bittorrent or other p2p system would be worthwhile looking into (this could even be investigated for the current rsync/distfiles system) but then hash/md5/etc checking would become very importand.

just a few ideas .... tho I would probebly stick with compiling everyting myself ;P 

Henti 





--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

begin  quote
On Thu, 10 Apr 2003 11:07:24 +0200
Henti Smith <bain@tcsn.co.za> wrote:

 
> if you want the latest binary for mutt
> running on 486 you need file
> mutt-1.5.4.486.tar.gz
> 
> for pentium 
> mutt-1.5.4.586.tar.gz 

why not ia32/486/mutt-1.5.4.tbz2 
why not ia32/586/mutt-1.5.4.tbz2 

> 
> etc etc .. 
> 
> this is logical .. and workable.

and my idea gives less files to list ;)

 
> USE flags.
> 
> This is a lot more tricky as use flags will effect alot of
> applications.

Stick to the defaults, if people want to change them, they can rebuild.
Reduces our headache, and  the problems with dependencies.


 
> 
> as to hosting the binaries ... maybe looking at something like
> bittorrent or other p2p system would be worthwhile looking into (this
> could even be investigated for the current rsync/distfiles system) but
> then hash/md5/etc checking would become very importand.

unfortunately, Bittorrent works best on larger files, due to design, and
it has to be in "constant use"  to be worthy.

 Gnutella is a viable system, if we change the way the clients work and
hook up. Background daemon to stay connected and share, wide node-splay
and then attempting to reconfigure so each node will "try" to connect to
nodes that have what we want.  follow that up with a front-end client to
send download requests from the dameon and theres something that might
work.

No, dont suggest giFT/OpenFT. It doesnt scale anymore:/   Freenet is an
idea, as is gnunetd, but both are laggy protocols, which is rather
negative in our case since people mind speed.

And yes, package signing would be really important for such a case.

//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Henti Smith]

On Thu, 10 Apr 2003 11:41:39 +0200
Spider <spider@gentoo.org> wrote:

> > if you want the latest binary for mutt
> > running on 486 you need file
> > mutt-1.5.4.486.tar.gz
> > 
> > for pentium 
> > mutt-1.5.4.586.tar.gz 
> 
> why not ia32/486/mutt-1.5.4.tbz2 
> why not ia32/586/mutt-1.5.4.tbz2 

Because portage downloads files in one dir ... the ebuild can be in that format .. 
there are many options .. but having as much details in the file name would make it easer to find files locally on on the net ... 

but it's just an idea :) 

> > this is logical .. and workable.
> 
> and my idea gives less files to list ;)

but harder to implement in portage .. I can see portgae admins frothing at themouth already about this thread ;P hehehe 

> Stick to the defaults, if people want to change them, they can rebuild.
> Reduces our headache, and  the problems with dependencies.

I agree with that one :) 

> unfortunately, Bittorrent works best on larger files, due to design, and
> it has to be in "constant use"  to be worthy.

I'm not very familiar with it .. so was just a mention :) 

>  Gnutella is a viable system, if we change the way the clients work and
> hook up. Background daemon to stay connected and share, wide node-splay
> and then attempting to reconfigure so each node will "try" to connect to
> nodes that have what we want.  follow that up with a front-end client to
> send download requests from the dameon and theres something that might
> work.

This can release alot of load from the distfile mirrors ... and should really be looked at,
esp if one of the mirrors go down etc etc there is another machine with the files availible .. 

> No, dont suggest giFT/OpenFT. It doesnt scale anymore:/   Freenet is an
> idea, as is gnunetd, but both are laggy protocols, which is rather
> negative in our case since people mind speed.

I'm not very clued up on p2p .. I don't personally use it often if at all, but I think 
distributed system for distfiles can be very successful for gentoo ... for both source and binary systems.

> And yes, package signing would be really important for such a case.

agreed :) 

Henti 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Noah Justin Norris]

	Have you ran debian lately, can you even say its a current binary distro 
(current as of redhat 6) and why do people not like using mandrake and redhat 
after they start using linux one they are a company and not a community and 
two RPM's based distro break 

	Is there a way to make like a i586 or i686 based distro but optimize it for 
all the above faster processors ( i know there a reason for -mcpu= )   i 
really dont think i386 and i486 binary's are needed   (debian works great for 
these cause the systems are just about as old as debian current)

	I didnt want to cause a flame war over this,  this is the type of response i 
get from  debian user's  i dont want gentoo  becoming like debian in this 
sence. 

	Another issue is portablity how hard is it to release source based cd's 
(containing all the gentoo source which possible could be updated weekly or 
monthly) this would target mostly dialup linux users or users with restricted 
net access. this was worked on then kinda disapeared . ? 


On Thursday 10 April 2003 06:28 am, leahcim@ntlworld.com wrote:
> On Thu, Apr 10, 2003 at 12:13:30AM +0000, Noah Justin Norris wrote:
> > 	Is there any interest to start a binary release of gentoo with
> > precompiled binaries. Im talking the entire source tree i know many
> > people that would switch to gentoo if they would not have to compile
> > every thing from source . not everyone has the fastest computer out
> > there.
>
> I thought it was called Debian? ;o)
>
> Or perhaps, "I'd eat meat, if only it were vegetarian"
>
> Seriously though, I don't see the point, unless you want to sell more
> T-Shirts, there are a plethora of good binary distributions of linux out
> there already and all the downsides you list are what, imo, define Gentoo.
>
> I'd prefer to see gentoo improved as a source-based distribution

-- 
life is linux 
linux is life 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

On Fri, Apr 11, 2003 at 01:16:32AM -0700, Miles Egan wrote:
> I help manage a linux compute cluster of about 1500 nodes.  We run 
> Redhat.  Gentoo isn't even an option without something like kickstart 
> and binary package support as good as rpm's.
I have experience of running a slightly smaller cluster, and I have
tried Gentoo on them. however no matter what distribution I did find the
most effective way since the machines were homogenous was actual system
imaging.

If I want to reimage a machine, I just blast the MBR remotely, and then
we have them configured to netboot, and they netboot into a minimal
linux with some custom applications we wrote that do system imaging over
multicast on a fixed schedule.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[gentoo-dev] Re: Binary release of gentoo

[Peter Simons]

Cedric Veilleux writes:

 > Gentoo already supports binary packages anyways [...]. We're only
 > talking about improving it AFAIK.. What's wrong with improving some
 > features of portage if it's possible and if it won't hurt anyone?

There are about a gazillion different Linux distributions out
there, and all of them have their own bunch of supporters, who can
get quite emotional arguing why _their_ system is superior to the
rest. This fact suggests that different people have different needs
and taste -- and that makes it quite obviously impossible to build
a system everybody will like.

Considering this, Gentoo should identify its core strength and
focus on _that_, because _that_ is the reason why its users prefer
Gentoo over all the other systems. Trying to attract users from
other groups with features they might like, but about which your
core users do not care, is a foolish thing to do. All you'll
achieve is messing up a wonderful distribution.

Now, I cannot speak for others, but the reason why _I_ use Gentoo
is because it is source-code--based and clean. Binary distributions
are of no interest to me. What I care for is to get the technically
most ad'fucking'vanced source-code--based Linux distribution known
to man. Let's be honest: Binary distributions are for men with no
hair on their chest. Mouse pushers. Let them use SuSE. They don't
deserve better.

Peter


P. S.: My god, we Genntoo users are the best, aren't we? :-)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Matt Thrailkill]

I would love this.  I've been thinking about this for a while and have been meaning to ask about it on this list.  Reason I'd like it, rather than using Debian?

1) I like portage.
2) I like gentoo.
3) I like using gentoo more than debian, just compiling can be a pain sometimes.

Gentoo is inspired by FreeBSD.  I'd like to see something analagous to all of the pkg_* tools in FreeBSD.  That would simply rock.  Then it'd be practical to put Gentoo on slower systems or systems where you don't need or want to be compiling all the time, like a server.

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.  Require the binaries to be built against the USE flags and CFLAGs from the GRP or something.  I think standardized cflags and use flags are a fair tradeoff for getting binary packages at all.  Might even help QA in a sense, place more inertia and importance on what is selected for the GRP and so on.  If ebuild maintainers have to send in a standardized binary pkg as well, might compel them to craft better ebuilds and so on.

I guess other people use Gentoo solely because it compiles everything, but I don't.  I run it on my desktop and laptop, but forego it on my servers because I don't want to compile so often (and its so bleeding edge, another nice thing would be to have more granularity in choosing which trees to follow, i.e. like -RELENG, -CURRENT, -STABLE in FreeBSD).  There's been times on my laptop when I'm somewhere and I want to try an app like such and such packet sniffer, and I have to sit there and compile for 15 minutes.  Being able to just do `pkg_add -r ethereal` would be a godsend in cases like that.

Some people get all offended and religious when the idea of binaries is suggested, like it would slight the ability to use source packages, but I think they could be made to fit together just like the binary packages and Ports tree under FreeBSD.

If anything, just start off slow and let the maintainers add binary packages for the ebuilds over time.  You see things like openoffice-bin, and alot of people seem to use it, so certainly the utility is there.

Yea, and I'm sending this off now before reading other people's responses because I have to go somewhere soon.  I look forward to reading all that's been said when I come back, hope I don't look retarded for speaking too soon.

On Thu, 10 Apr 2003 00:13:30 +0000
Noah Justin Norris <gentoo@mchsi.com> wrote:

> 	Is there any interest to start a binary release of gentoo with precompiled 
> binaries. Im talking the entire source tree i know many people that would 
> switch to gentoo if they would not have to compile every thing from source .  
> not everyone has the fastest computer out there.
> 
> 	I would be internested in helping work on a binary port of gentoo. I know 
> there would be some issues with having a binary port
> 	1. use settings  ( maybe have 2 versions of apps one clean andone loaded ie 
> kde and gnome support)
> 	2. cflags  (maybe support multible processors i586 i686 pentuim3 pentuim4 
> etc)
> 	I believe there will be others . i have alot of computers and Im willing to 
> help out sence and I have lots of free time
> 	 I know this is possible though I have built packages on one machine and 
> installed them on other slower machines.
> 	
> 	Note > im not talking about a grp like install thats on a cd , but as a new 
> edition to the portage ebuild system as a whole  IE: setting in make.conf 
> makes emerge get binarys .
> 
> 
> -- 
> life is linux 
> linux is life 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Jon Portnoy]

On Fri, Apr 11, 2003 at 01:16:32AM -0700, Miles Egan wrote:
> Spider wrote:
> 
> >I know I'd welcome it, as a far simpler way of installing and keeping my
> >celeron running..    But I think it'd require some more portage hacking
> >to "make it work", at least the following.
> 
> I help manage a linux compute cluster of about 1500 nodes.  We run 
> Redhat.  Gentoo isn't even an option without something like kickstart 
> and binary package support as good as rpm's.
> 
> miles
> 
> 
> 
> --
> gentoo-dev@gentoo.org mailing list

Put buildpkg in FEATURES and you'll have binary packages just as good as 
RPMs built automatically every time you merge something.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 3530 bytes --]

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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Mark Farver]

On Thu, Apr 10, 2003 at 10:34:23PM +0300, Dan Armak wrote:
> 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 

This is more an idea on how to help mirroring.. but I'll throw it into this discussion since it could
also be used for sharing binary tarballs. 

How about someone creating an module that automatically shares the contents of /usr/portage/distfiles
(or packages) over a peer to peer network like gnutella.  
Everytime someone trys to emerge a package, portage checks the peer network to see if someone
has a binary package already built (with the same USE flags set) and if not it looks for a nearby
copy of the tarball.  This could be used to spread the ibiblio/oregonstate load out a bit... 

This would be easpecially useful for places like my office, where we have several dozen gentoo
workstations, and a mediocre 256kps SDSL internet link.  Since they are all basically running the
same hardware, and have the same use flags set the binary option could be used to speed installation
of new packages. 

The big drawback for the binaries is there is no guarentee they are what they say they are, unlike
the tarballs that at least have the MD5 from the ebuild.

It would be an actual example of "significant non-infringing use" of a p2p network.  ;-)

Mark Farver


-- 
"The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding."
-- Justice Louis O. Brandeis, Olmstead vs. United States

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1958 bytes --]

On Friday 11 April 2003 00:54, Mark Farver wrote:
> This is more an idea on how to help mirroring.. but I'll throw it into this 
discussion since it could
> also be used for sharing binary tarballs. 
> 
> How about someone creating an module that automatically shares the contents 
of /usr/portage/distfiles
> (or packages) over a peer to peer network like gnutella.  
> Everytime someone trys to emerge a package, portage checks the peer network 
to see if someone
> has a binary package already built (with the same USE flags set) and if not 
it looks for a nearby
> copy of the tarball.  This could be used to spread the ibiblio/oregonstate 
load out a bit... 

Wrt. distfiles:
For an intranet, is that much better than having one box serve them centrally?
For the internet, sharing distfiles/ on a p2p network requires a _good_ 
uplink. Again, not the 56k dialup people. And those who have such an uplink 
probably don't worry too much about fetch times anyway. (Remember to use 
alternative mirrors, not ibiblio)

> The big drawback for the binaries is there is no guarentee they are what 
they say they are, unlike
> the tarballs that at least have the MD5 from the ebuild.

On an intranet you might take such a risk. On the internet I'd never agree for 
my machine to use an untrusted, anonymous source for binaries.

BUT: once we have pgp digest signing in place, you'll be able to specify 
trusted pgp keys and accept packages signed by them (or rather whose digests 
have been signed by them) and that is the perfect situation for building a 
pgp web of trust among gentoo users - assuming people really do follow the 
strict pgp rules of verifying identity before trusting a key.

But still, not for 56k people, not if you expect them to upload anything in 
return anyway. 

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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Matt Thrailkill]

On Thu, 10 Apr 2003 22:34:23 +0300
Dan Armak <danarmak@gentoo.org> wrote:

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

I'm sorry, this totally slipped my mind.  That would suck, especially if you're the KDE maintainer.  Your special build server would probably be more desirable then.


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

Curious though, how much time is spent trying to build such and such an ebuild until you actually get it right and then finally compile something that works and installs fine on your box?
 

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

Do you think the onus is more on finding machines to compile it all with or machines to host it all with?  I would think that some hotrodder overclocker types, the kind that run Gentoo cause they like watching gcc scrolling in an xterm, would be able to get an impressive distcc farm built out of the boxes they personally own.  Ibiblio probably wouldn't be happy hosting binaries though.


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

On the subject of GRP being enough, its definately a big step in the right direction.  When I look at Gentoo, I see something that has the potential not just to have the nice features of FreeBSD, but to improve on them and have the capacity to be more bleeding edge.  Not just as a machine to let me build everything with extreme CFLAGS.  Long term, optional binaries of most everything is something I'd like to see, just like what FreeBSD lets you install with pkg_add.  That, and being able to sync my Portage tree to different revisions (like -RELENG_1_4 or -CURRENT or -STABLE or whatever).  But thats longterm and just me, its just my suggestion, you guys are the ones doing the work and I'm thankful for all you've done already.  Am I being too much of a FreeBSD whore?

Btw, how big are the generated packages if you do, say, `emerge -b kde`?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Spider]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

begin  quote
On Thu, 10 Apr 2003 14:57:11 -0400
Jon Portnoy <avenj@gentoo.org> wrote:


> Put buildpkg in FEATURES and you'll have binary packages just as good
> as RPMs built automatically every time you merge something.

not 100% really, since theres no automatic signing/hash of the packages
(rpm has this, good feature)
as well as some rebuild dependencies might not be resolved..

foo depends on gal, but gal removes the softlinks and forces
dependencies to rebuild or retain the old version..  such things should
ofc. be resolved (gal is a problemchild in general) but, we lack that
functionality.


Theres a few other "good" things about the rpm format, although it isn't
as flexible as our packages are ;)



But, my point was about distribution of this. how/wether it is a
good/bad and even doable thing


//Spider


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Terje Kvernes]

Matt Thrailkill <xwred1@xwredwing.net> writes:

  [ ... ]

> Btw, how big are the generated packages if you do, say, `emerge -b
> kde`?

  bad example, as 'kde' is a meta-package, but for KDE my 2.95-based
  box gives:

$ pwd; ls -oSr kde*3.1.1[^a-]*
/usr/portage/packages/All
-rw-r--r--    1 root         1784 Mar 23 23:05 kde-3.1.1.tbz2
-rw-r--r--    1 root      1066574 Mar 23 22:27 kdeaddons-3.1.1.tbz2
-rw-r--r--    1 root      1266163 Mar 23 23:05 kdeadmin-3.1.1.tbz2
-rw-r--r--    1 root      1573634 Mar 23 17:31 kdetoys-3.1.1.tbz2
-rw-r--r--    1 root      1677483 Mar 23 14:01 kdeutils-3.1.1.tbz2
-rw-r--r--    1 root      2923458 Mar 23 20:58 kdepim-3.1.1.tbz2
-rw-r--r--    1 root      5051980 Mar 23 21:55 kdegraphics-3.1.1.tbz2
-rw-r--r--    1 root      5735141 Mar 23 19:38 kdenetwork-3.1.1.tbz2
-rw-r--r--    1 root      6808017 Mar 23 12:37 kdemultimedia-3.1.1.tbz2
-rw-r--r--    1 root      8960754 Mar 23 13:32 kdegames-3.1.1.tbz2
-rw-r--r--    1 root     12277239 Mar 23 22:40 kdeartwork-3.1.1.tbz2
-rw-r--r--    1 root     14566073 Mar 23 14:49 kdeedu-3.1.1.tbz2
-rw-r--r--    1 root     17815125 Mar 23 17:20 kdebase-3.1.1.tbz2

  as a sidenote, GCC3.2 on my 3.2-based box is another 30MiB.  :-)

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[DJ Cozatt]

-snip-
> > 
> > Ditto. There is no point to a binary version of Gentoo. If you want that then 
> > as Michael said just use Debian.
> 
> Actually I think a binary version would be pretty cool.  I use Gentoo 
> mainly because it tracks new versions of packages so much better than 
> debian.  In fact, I think I switched from debian out of frustration 
> waiting for debian to package kde 3.1.  Compiling from source is cool 
> too but it's not what keeps me on Gentoo.
> 
> miles
> 

 what about people on dial-up? If they can have a stable binary of X
or Gnome/KDE and OpenOffice perhaps.. and still have source based for the underlying stuff? Rather than have to download and compile these
huge ones? Or is that where GRP is headed?

 As long as there really is a performance/stablility/feature advantage for running Gentoo. Of course that means new binaries if there is a security issue.

 Binary distributions are often accompanied by a nice glossy version of 
the installation docs and sold at a nice price too.

 David

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[John White]

It is pretty clear to me that binary distribution is not in the
cards from the maintainers of Gentoo.  It's a hard enough job
just managing the ebuilds.

It's also a pretty clear violation of the definition of Gentoo,
"ports-based."  I think it was Dylan Carson who used the phrase
"out of scope."  I like that.

It's also pretty clear that some people think it's a good idea,
or at least an idea worth discussing.  I think that's great.
So why don't you discuss and implement?  And not here, in a 
place dedicated to it.  I mean if you can't get MLM infrastructure
in place, you might as well give up on the idea of a linux 
distribution.

-- 
John White

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Matt Thrailkill <xwred1@xwredwing.net> wrote:

>If ebuild maintainers have to send in a standardized binary pkg as well, might >compel them to craft better ebuilds and so on.

Not to rock the boat, but what if ebuild maintainers, who manage so many packages that they are consistently putting out a call for help, decided maintaining them wasn't worth that extra time and resources?

And what about the anti-devs? non-devs? such as myself and quite a few other people, who submit ebuilds or changes to ebuilds, whose CFLAGS might be less than desirable for you? And what is standard? i386? higher? Debian and RedHat provide i386 packages, probably similar with *bsd's, Mandrake doesn't do less than i586 now, so where is the standard at? Who gets left in the cold?

As a side note to devs, you could get more help with a lower package load. I honestly don't have the time for a full category to maintain, but hell, I already unofficially watch six or eight packages now, wouldn't bother me to do it officially:P

Anyways, to put up my reasonable counter offer, it might be easier to have like a big list where people can say "These are my build and USE flags, and these are what packages I am willing to send people binaries of if they're interested", and then have like a volunteer effort of binary swapping between people. Just a general idea, I'm not gonna work out the logistics of it:)

-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Miles Egan]

Robert Cole wrote:
> On Wednesday 09 April 2003 11:28 pm, leahcim@ntlworld.com wrote:
> 
>>On Thu, Apr 10, 2003 at 12:13:30AM +0000, Noah Justin Norris wrote:
>>
>>>	Is there any interest to start a binary release of gentoo with
>>>precompiled binaries. Im talking the entire source tree i know many
>>>people that would switch to gentoo if they would not have to compile
>>>every thing from source . not everyone has the fastest computer out
>>>there.
>>
>>I thought it was called Debian? ;o)
>>
>>Or perhaps, "I'd eat meat, if only it were vegetarian"
>>
>>Seriously though, I don't see the point, unless you want to sell more
>>T-Shirts, there are a plethora of good binary distributions of linux out
>>there already and all the downsides you list are what, imo, define Gentoo.
>>
>>I'd prefer to see gentoo improved as a source-based distribution
> 
> 
> Ditto. There is no point to a binary version of Gentoo. If you want that then 
> as Michael said just use Debian.

Actually I think a binary version would be pretty cool.  I use Gentoo 
mainly because it tracks new versions of packages so much better than 
debian.  In fact, I think I switched from debian out of frustration 
waiting for debian to package kde 3.1.  Compiling from source is cool 
too but it's not what keeps me on Gentoo.

miles


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Miles Egan]

Spider wrote:

> I know I'd welcome it, as a far simpler way of installing and keeping my
> celeron running..    But I think it'd require some more portage hacking
> to "make it work", at least the following.

I help manage a linux compute cluster of about 1500 nodes.  We run 
Redhat.  Gentoo isn't even an option without something like kickstart 
and binary package support as good as rpm's.

miles



--
gentoo-dev@gentoo.org mailing list

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@gentoo.org mailing list

Re: [gentoo-dev] Binary release of gentoo

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2134 bytes --]

On Friday 11 April 2003 02:01, Matt Thrailkill wrote:
> > 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.
> 
> Curious though, how much time is spent trying to build such and such an 
ebuild until you actually get it right and then finally compile something 
that works and installs fine on your box?

Well ok, 'twice' isn't accurate. But it still does mean another full build of 
everything I commit, which is a lot by the same calculation that says it 
would take dedicated server(s) to do this. And we don't all have server-class 
development machines at home. The remote developers'-build-server is much 
better.

> Do you think the onus is more on finding machines to compile it all with or 
machines to host it all with?  I would think that some hotrodder overclocker 
types, the kind that run Gentoo cause they like watching gcc scrolling in an 
xterm, would be able to get an impressive distcc farm built out of the boxes 
they personally own.  Ibiblio probably wouldn't be happy hosting binaries 
though.

The hotrodders are ruled out for the same reason a p2p network is - we 
wouldn't be able to trust them (maybe a few we know, but not just anyone who 
has gentoo and a fast box). We need a server we can control and make sure is 
secure.

If we have a lot of uptodate GRP packages, usage will spread very very rapidly 
and downloads will rival or perhaps pass distfile downloads (remember that 
only a part of the latter goes through our mirrors, some still download from 
packages' homesites). So even if all our existing mirrors ageed to host this 
too, it would more than double the bandwidth we'd use up. It would also 
multiply many times the amount of spaec we take on a mirror, because every 
package would exist for a geat many archs.


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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 495 bytes --]

On Friday 11 April 2003 05:01, DJ Cozatt wrote:
>  what about people on dial-up? If they can have a stable binary of X
> or Gnome/KDE and OpenOffice perhaps.. and still have source based for the 
underlying stuff? Rather than have to download and compile these
> huge ones? Or is that where GRP is headed?

AFAIK that's the main reason for grp, yes.


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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Binary release of gentoo

[Jon Kent]

Been following this over the last day, comments I'd
like to make are (and they have been said b4):

- Gentoo is sourced based first and foremost
- GRP is there to cover some of the big packages
- If you really want binary packages pls use another
distribution or try the grp packages if you haven't

Sometimes you need to ask yourself if you really need
to upgrade to the latest and greatest, or whether you
can wait for a big release.  Hell, I've still got one
of my PCs running Gentoo 1.2 and it does everything I
need of it, so I'm not in a rush to upgrade.

I suppose I'm lucky as I have a nice big pipe out to
the internet at home and a meaty machine as my main
workstation so compiles are not too much of a hassle. 
But at the end of the day I assume you choose Gentoo
because of its many good points, and being sourced
based is one of the main ones IMHO.

Pls, can we knock this one on the head and instead
look at helping out on the GRP effort.

Ta much,

Jon


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

--
gentoo-dev@gentoo.org mailing list