1 |
> You're right, they probably don't. My system will be quite modular and I image |
2 |
> a new tree, maybe I'll implement it in the initial release. One concept I'm |
3 |
> thinking about is something I call xpack (where xbuild is the extension of |
4 |
> ebuilds that should be guaranteed to work with the new parser). This basically |
5 |
> is a text based packaging format (like tar, but actually diffeable), that |
6 |
> would contain all parts needed for an ebuild (source is optional). Such a file |
7 |
> would make things a lot easier to manage and to download on demand. |
8 |
|
9 |
Totally agree. You can also force a validating commit with cvs : any |
10 |
commit would have to pass QA test (parsing) to be really commited. |
11 |
But, please consider not using rsync anymore. It's too slow for 85 000 |
12 |
files :( |
13 |
as previously discuss, subversion would be great. The best way is maybe |
14 |
the debian way : Put all xbuilds in a single tar file that would |
15 |
downloaded when "emerge update" (example). |
16 |
|
17 |
> While my main focus will not be on ondemand downloading of xpacks (ebuilds is |
18 |
> pointless) it should be fairly trivial to generate metadata files for the |
19 |
> packages contained, maybe even on a category level. The transfer size could |
20 |
> still be sizeable though. I believe that introduction of xpack files |
21 |
> containing everything needed for an ebuild (except the manifest and |
22 |
> metadata.xml) allready reduces the amount of files in the tree enormously. It |
23 |
> also helps in being able to easilly remove unused patches ;-). |
24 |
|
25 |
I like this new portage :) |
26 |
So these xbuilds are not needed on end-users computers. They are only |
27 |
needed to generate the dependance tree. |
28 |
|
29 |
If you need any help on this, please email me. |
30 |
|
31 |
Philippe |
32 |
|
33 |
-- |
34 |
gentoo-portage-dev@g.o mailing list |