Here's another idea, how about setting up the distcc package on a bunch of fink developers' machines to help build the binary distributions? (Yes, with the default compiler settings binaries are compatible with both G3 and G4).
I have a G4 dual-450, 10.2.3, stable IP, and would be willing to participate in a fink distcc network (but I have no time co-ordinate it myself, many real-life obligations coming up).
We'd probably have to do some tests to see how many machines would be needed to make it worthwhile.
Carsten
On Friday, January 17, 2003, at 08:19 am, David wrote:
Hello All.
I am sorry that I am not contributing regularly this month and iI am sorry have not done so in December. Both months are traditionally busy in my line of work.
However I read the request by DRM to add a new set of fields and I did follow the discussion a bit. As far as I have understood building such a distribution is not exactly trivial and it needs computing power as well. The packages would have to be compiled into debs as far as I know and that takes some time depending on the size of the package.
What I am proposing might sound a bit strange but listen to me for a minute. Let us assume that my work is successful and I can urge many authors to put their packages into stable, which would mean they are available for a distribution. We might end up with , let us assume 2000 packages in stable , some of them might be quite large taking 2 or 3 hours to compile maybe more.
If we could build a distributed build system for the distribution itself we would run around the bottleneck of having one "build farm", which we do not have right now as far as I have understood.
I am no Apple guru, but aren't the binaries produced on g3 and g4 binary compatible? That was someone with 4 dual G4 and someone with a TiBook could help build packages.
For that we would need:
a) A Main database server which holds:
1) Which packages may be built by the User (a tiBook users might not be too happy building KDE)
2) Which packages have been built
3) Which packages need a rebuilt due to changes.
4) Which builds are currently in progress
5) Which packages may be built at all.
b) A client which can:
1) distinguish what packages it may get for building
2) negotiate all the necessary control information before and after a build has finished
3) return the package once it has been properly built into a deb.
I am sure there are many caveats we will come across should we further indulge this idea, yet I wanted to get it out, after all it might be a good one.
There is much distributed computing going on and this would be just something that abuses the basic idea of it, a small not really concise form of grid computing *grin*
Thank you
- -d
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
