Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-soc
Navigation:
Lists: gentoo-soc: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-soc@g.o
From: mmacleod@...
Subject: Re: Improved binary package support
Date: Wed, 25 Mar 2009 11:47:23 +0200
> > <snip>
> Now I understand. I think it is not necessary to provide all possible
> USE-flag combinations (PHP alone would use more space than you
> projected, I think).
It is certainly infeasible either way to provide any large quantity of 
combinations from one central server, not unless someone donates a really 
impressive cluster with a really large SAN which I don't see happening any 
time soon.
Even with the p2p idea compiling every single package with every single use 
flag is probably way out of reach, but this is unnecessary the p2p idea 
doesn't strive to have packages for absolutely everything but rather just to 
collect packages for everything that people HAVE compiled in order to avoid 
unnecessary replication by other people.
> We should take some defaults (maybe 4-5 possible
> combinations of USE-flags) and, as i said, lots of packages don't have
> certain USE-flags and need only be compiled once for all our defaults.
This defies the entire spirit of use flags as it will mean there are only 
binaries available if you use a specific set of use flags, at this point you 
lose any benefit Gentoo has over a normal binary distribution.
Yes it would be better then nothing but it would not change the fact that many 
people will have to recompile the exact same thing that many other people are 
recompiling, which is the entire problem my idea is trying to address.
It would be very nice to have something like this as part of the p2p binary 
idea, but to suggest this as a replacement for the idea is missing the point 
in my opinion.
Anyway I guess we differ on this so there is no point arguing further in 
circles on it.
> > But you only have packages for one set of USE flags, as portage does
> > not currently store packages for different USE flags.
> > Unless you are implying that the majority of users all have the same
> > CFLAGS/Use flags and Programs as you it is unlikely that your 6 GB
> > set would be anywhere near close to being able to provide usable
> > binaries for many people.
> This is where cooperation with the stats project would be really great.
As I mention at the end of the email having statistics could help, but I 
suspect you will find that there are many different use flag combinations and 
that not enough people use the same identical use flags that compiling 
binaries for only that set of use flags would be sufficient for a large 
portion of Gentoo users to be able to use binaries.
> > Sure even having the basic stuff available is a nice *start* but
> > where are they going to be hosted and who is going to compile them,
> > and using what server?
> I think that could be managed. If you only build a subset and not all
> USE-flag combinations, maybe someone could donate some VM.
That is quite a big maybe, I am not prepared to work on something that relies 
on a possible donation that may never materialize. I would rather work on 
something like my idea that can start without any donation and then make use 
of donations as they become available, I find that people are far more likely 
to donate to something that already works personally.
> > I am not sure what you mean here by not building everything again?
> Maybe you have some different USE-flag profiles, let's say, kde and
> gnome (enabling the needed flags, disabling the ones for the other
> desktop environment). Then you only need to provide one binary package
> for openssh, because it is not affected by the USE-flag differences.
However how is this going to help people who want openssh to have kerberos 
support when kerberos is disabled in both of those profiles? This will only 
allow people to use binaries in some lucky cases and then force them back into 
compiling the instant they want to do something different. In fact this will 
act as an incentive not to do anything different which is the exact opposite 
of what Gentoo means to me.

The whole point of the p2p idea is that there are already people out there 
compiling all of these things every day, and that if that work can be 
collected others can be saved from having to repeat the same process(If they 
are lucky enough to be using the same flags as someone before them, if not 
then they can donate there work and save others that come after them)
No extra work is required other then tracking what people have compiled and 
sharing it in some way, and some security measures of course.
Furthermore no statistics are even required as the idea is self regulating, if 
a use flag combination is popular then a package will already be available for 
it from someone else, if it is not popular then it won't be available.
There are nice ways to improve this somewhat in the long run if some kind 
person does magically decide to donate some decent hardware, such as using 
that hardware to pre-generate binaries for popular packages and use flag 
combinations based on statistics without any user involvement,  but in the 
meantime this can already be started with absolutely no hardware.



References:
Improved binary package support
-- mmacleod
Re: Improved binary package support
-- mmacleod
Re: Improved binary package support
-- Philipp Riegger
Navigation:
Lists: gentoo-soc: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Improved binary package support
Next by thread:
Re: Improved binary package support
Previous by date:
Re: Improved binary package support
Next by date:
Gsoc Idea: EeePC Script/Build


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.