| 1 |
Hi! |
| 2 |
|
| 3 |
Info: If you are not interested in the first part of the mail, make |
| 4 |
sure to read the last few sentences. |
| 5 |
|
| 6 |
I participated in the discussion about improved binary package |
| 7 |
support here and on bug <https://bugs.gentoo.org/150031>. However, I |
| 8 |
don't see the _really_ distributed idea working: |
| 9 |
|
| 10 |
1) There is a huge number of packages and a huge number of |
| 11 |
configuration options (USE-flags). True, this would be much to do for a |
| 12 |
build server, but if you want to create trustworthy packages and say |
| 13 |
"100 packages with same hash prove it to be right", the overhead is |
| 14 |
even higher, I think. |
| 15 |
|
| 16 |
2) Lots of core packages do not need to be built for too many |
| 17 |
configuration options. Basic profiles for servers, Gnome, KDE, maybe |
| 18 |
something with LDAP, without LDAP, with Kerberos, without Kerberos |
| 19 |
would be enough for a lot of people. |
| 20 |
|
| 21 |
3) Those packages will never be trustworthy. I heard some arguments how |
| 22 |
they could be made trustworthy, I don't believe any of that can work. |
| 23 |
|
| 24 |
The points I want to see addressed are: |
| 25 |
|
| 26 |
1) Improved binary packages. This should be discussed, but for |
| 27 |
me it's the coded USE-flag bitvector and some kind of host imformation |
| 28 |
value (preferably a tree with 1-2 directory levels, full information in |
| 29 |
the xpak (or how it's called) addition. This should be as easy as |
| 30 |
possible and address everything needed for all approaches (p2p, |
| 31 |
buildserver, whatever) that people are interested in. |
| 32 |
|
| 33 |
2) Improved buildserver support. For me this includes profiles (like |
| 34 |
server, desktop-kde, desktop-gnome, be it in the tree or in the build |
| 35 |
system). Those should only affect USE-flags. They should not be stored |
| 36 |
in different directories and only be different in content of the |
| 37 |
package and filename. A package should only be built once for different |
| 38 |
profiles, if it's USE-flags are not affected (meaning bash should only |
| 39 |
be built once for kde, gnome and server profiles). |
| 40 |
|
| 41 |
3) Some kind of detection for broken packages. We could check all |
| 42 |
binary packages we already built (maybe we don't need to install them |
| 43 |
but can create all the info revdep_rebuild creates after building a |
| 44 |
package and write it to the meta information). We should then rebuild |
| 45 |
all broken packages and tell the user to reinstall that package (use a |
| 46 |
binary revision like the -r already used, increase it when recreating a |
| 47 |
package, portage sees it as a higher version and upgrades). We should |
| 48 |
take care that updated packages and all needed updated reverse |
| 49 |
dependencies get to the server at the same time (1 commit in svn or |
| 50 |
whatever). |
| 51 |
|
| 52 |
There is no p2p stuff in here since I don't believe in it. I see 1 way |
| 53 |
to make this work: Create a p2p network of only gentoo developers (ok, |
| 54 |
maybe arch testers), make them sign the packages using gpg. Other |
| 55 |
people can only mirror packages, not add new ones. That they do not add |
| 56 |
new ones is important that the (trustworthy) packages by gentoo |
| 57 |
developers get distributed faster and better. But I still prefer the |
| 58 |
build server approach. |
| 59 |
|
| 60 |
Important Info: If anybody wants to do this for SoC (not exactly what I |
| 61 |
proposed but something with binary packages in the title) and if he |
| 62 |
wants to do something involving build servers which sounds possible and |
| 63 |
makes sense, I can provide him with a virtual machine, enough RAM, 1-2 |
| 64 |
cores (have to check back how much we can spare) and enough disk space |
| 65 |
(for a test installation involving 1-2 arches and not too many |
| 66 |
USE-profiles). |
| 67 |
|
| 68 |
Philipp |
Archives