Re: [gentoo-soc] Improved binary package support

> Would getting hashes to agree be a hard thing to accomplish?
There are probably some packages that will give difficulty, and a few things 
to consider but it should not be unreasonably hard.
> If you use
> the binary build feature in portage you could save the build in a
> compressed format.
This is the idea yes, to improve the binary feature of portage and then take 
advantage of it as part of this system.
> Then have a hash generate set up where it would take
> the name, version, and use flags, cflags and hash just that information.
We are talking about two different types of hashes.
There would be a hash in the package names in order to tell the difference 
between package foo compiled with use flag "bar" and package foo compiled 
without useflag "baa"(It would also have to take into account cflags and 
dependency versions), this is part of the "improved binary support idea".

The second kind of hash that I am talking about now is a security hash 
computed over the final package file. By having multiple users compile the 
package and generate a security hash of it one can ensure(within reasonable 
doubt) that the package has not been tampered with by the contributor, by for 
example adding a rootkit to the source code.
> Have a program that would run as a deamond on compter it could update
> themselves to something like a torrent tracker.  The torrent name could the
> the hashed values.  Then we could have the data that would need to be
> installed passed via torrent to all other users. It would be an interesting
> implementation. Also you could use a DC++ idea and have a hub set up where
> you could only share compiled programs?
This is roughly what I am proposing, except with a bit more security built in 
to prevent tampering with packages as well as a bit more work required to 
decide who will host/seed what.
> This would make the idea distributed so it would not have to have ~10451G
> of space used on any single server.  People would host 'packages' as they
> compiled them.  The more comon the program was, the faster the downloads
> would be.
Yes, except there are security concerns so its a bit more complex then just 
one user compiling something and then everyone using it. There would have to 
be redundant compiles to prevent tampering, as well as tracking of where 
packages came from.
The main concern isn't really fast downloads though but rather distributing 
the large quantity of hard drive usage required and the CPU time of compiles.
> Another use would be releasing common programs/sets as packages? Example,
> Xorg. There are tons of programs that go along with it.  If you host
> commonly used programs on a service then people could download the program
> and use it while they compiled it with their own use flags.  We could offer
> programs with all flags enabled, the package manager would go get the
> prebuild program, keep track of all the files and then start the custom
> build according to the users own settings.  After the build is done, before
> it is moved from its sandbox, purdge the old files from the downloaded,
> pre-compiled code, and then move the files from the sand box.
The idea is that binaries of as many packages with as many different use 
flag/cflag etc.. combinations would be available as possible. It would be self 
regulating in that the more people who use a particular use flag/cflag 
combination the more likely a binary will already exist so the more popular 
stuff will always have binaries available first. If you use some really wacky 
cflag combination then you can't really expect that binaries will be 
available.

People will be able to use these binaries with a normal emerge command 
provided they enable support for it...

So emerge Xorg would download the appropriate Xorg binary if one existed, if 
there was not one it would instead compile it as normal.