| 1 |
Am Montag, 15. Juni 2009 08:23:30 schrieb Arne Babenhauserheide: |
| 2 |
> Am Freitag, 12. Juni 2009 17:05:33 schrieb Jeremy Olexa: |
| 3 |
> > > It seems that whole process could be sped up by hosting binary |
| 4 |
> > > packages on one central server (Binary host). Obviously various |
| 5 |
> > > versions of the same package would be created and therefore unique |
| 6 |
> > > names could be created by using some metadata to create hash part of |
| 7 |
> > > filename. On a first thought I would use USE flags and DEPEND as |
| 8 |
> > > metadata to hash. |
| 9 |
> > |
| 10 |
> > This is a cool aspect of the project, I hope you can work with solar |
| 11 |
> > and zmedico to improve binpkgs. USE flags seem to be the trouble spot |
| 12 |
> > of binpkgs. |
| 13 |
> |
| 14 |
> "Include more info about a binpkg" |
| 15 |
> - http://bugs.gentoo.org/show_bug.cgi?id=150031#c7 |
| 16 |
... |
| 17 |
> $PKGDIR/$CATEGORY/$PN/$SLOTS_HASH/$USE_HASH/python-2.5.2-r8.tbz2 |
| 18 |
|
| 19 |
I forgot to include one unsolved question (sorry): How to specify the binary |
| 20 |
dependencies of the package? |
| 21 |
|
| 22 |
Sadly this isn't as easily solved in general (at least I don't know how), but |
| 23 |
for a centralized build server you could just add binary revisions to the |
| 24 |
binpackage names and use a simple file to map the binary revisions to binary |
| 25 |
dependencies - or just the versions of the dependencies they were built with. |
| 26 |
|
| 27 |
For finding the correct binpackage binary revision, portage could then first |
| 28 |
check the highest binary revision, if the versions of all installed depencies |
| 29 |
are at least the versions the binpackage was build with (assuming a |
| 30 |
continuously working build-server which only updates binpackages of one |
| 31 |
version, if revdep-rebuild/@preserved-rebuild demands it). |
| 32 |
|
| 33 |
If the locally installed dependencies have lower versions than the ones the |
| 34 |
binpackage was built with, portage could successively check lower binary |
| 35 |
revisions, until one fits the locally installed packages (all dependencies |
| 36 |
have the same or lower revisions than the locally installed ones). |
| 37 |
|
| 38 |
This only solves the problem for a centralized server, but since that's what |
| 39 |
you'll likely be using it might fit. |
| 40 |
|
| 41 |
At least the needs of pure-binpackage builds would be completely satisfied |
| 42 |
using this option (if the server runs revdep-rebuild/@preserved-rebuild after |
| 43 |
each update and only publicise the binpackage after that check) - all others |
| 44 |
would need to run revdep-rebuild after each emerge which didn't use a |
| 45 |
binpackage because they need to check if a library update broke binary |
| 46 |
compatibility of an installed binpackage. I'm not sure if portage-2.2 already |
| 47 |
solves this problem using @preserved-rebuild, though, so this might already be |
| 48 |
solved :) |
| 49 |
|
| 50 |
Best wishes, |
| 51 |
Arne |
| 52 |
|
| 53 |
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- |
| 54 |
- singing a part of the history of free software - |
| 55 |
http://infinite-hands.draketo.de |
Archives