Am Montag, 15. Juni 2009 08:23:30 schrieb Arne Babenhauserheide:
> Am Freitag, 12. Juni 2009 17:05:33 schrieb Jeremy Olexa:
> > > It seems that whole process could be sped up by hosting binary
> > > packages on one central server (Binary host). Obviously various
> > > versions of the same package would be created and therefore unique
> > > names could be created by using some metadata to create hash part of
> > > filename. On a first thought I would use USE flags and DEPEND as
> > > metadata to hash.
> >
> > This is a cool aspect of the project, I hope you can work with solar
> > and zmedico to improve binpkgs. USE flags seem to be the trouble spot
> > of binpkgs.
>
> "Include more info about a binpkg"
> - http://bugs.gentoo.org/show_bug.cgi?id=150031#c7
...
> $PKGDIR/$CATEGORY/$PN/$SLOTS_HASH/$USE_HASH/python-2.5.2-r8.tbz2

I forgot to include one unsolved question (sorry): How to specify the binary 
dependencies of the package? 

Sadly this isn't as easily solved in general (at least I don't know how), but 
for a centralized build server you could just add binary revisions to the 
binpackage names and use a simple file to map the binary revisions to binary 
dependencies - or just the versions of the dependencies they were built with. 

For finding the correct binpackage binary revision, portage could then first 
check the highest binary revision, if the versions of all installed depencies 
are at least the versions the binpackage was build with (assuming a 
continuously working build-server which only updates binpackages of one 
version, if revdep-rebuild/@preserved-rebuild demands it). 

If the locally installed dependencies have lower versions than the ones the 
binpackage was built with, portage could successively check lower binary 
revisions, until one fits the locally installed packages (all dependencies 
have the same or lower revisions than the locally installed ones). 

This only solves the problem for a centralized server, but since that's what 
you'll likely be using it might fit. 

At least the needs of pure-binpackage builds would be completely satisfied 
using this option (if the server runs revdep-rebuild/@preserved-rebuild after 
each update and only publicise the binpackage after that check) - all others 
would need to run revdep-rebuild after each emerge which didn't use a 
binpackage because they need to check if a library update broke binary 
compatibility of an installed binpackage. I'm not sure if portage-2.2 already 
solves this problem using @preserved-rebuild, though, so this might already be 
solved :)

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de