| 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 |
| 5 |
basically |
| 6 |
>> is a text based packaging format (like tar, but actually diffeable), that |
| 7 |
would contain all parts needed for an ebuild (source is optional). Such a |
| 8 |
file |
| 9 |
>> would make things a lot easier to manage and to download on demand. |
| 10 |
> |
| 11 |
> Totally agree. You can also force a validating commit with cvs : any commit |
| 12 |
would have to pass QA test (parsing) to be really commited. But, please |
| 13 |
consider not using rsync anymore. It's too slow for 85 000 files :( |
| 14 |
> as previously discuss, subversion would be great. The best way is maybe the |
| 15 |
debian way : Put all xbuilds in a single tar file that would downloaded when |
| 16 |
"emerge update" (example). |
| 17 |
|
| 18 |
Well it should be easy to have a different source of tree information. I like |
| 19 |
subversion (I maintain the ebuilds), but it does need to stand up to the load |
| 20 |
that the developers and users put on it. Subversion is also rather hard to |
| 21 |
mirror so we might want to look to other solutions or have mirrors only mirror |
| 22 |
the head revision not the below revisions ;-). |
| 23 |
|
| 24 |
> |
| 25 |
>> While my main focus will not be on ondemand downloading of xpacks (ebuilds is |
| 26 |
>> pointless) it should be fairly trivial to generate metadata files for the |
| 27 |
packages contained, maybe even on a category level. The transfer size could |
| 28 |
still be sizeable though. I believe that introduction of xpack files |
| 29 |
containing everything needed for an ebuild (except the manifest and |
| 30 |
metadata.xml) allready reduces the amount of files in the tree enormously. |
| 31 |
It |
| 32 |
>> also helps in being able to easilly remove unused patches ;-). |
| 33 |
> |
| 34 |
> I like this new portage :) |
| 35 |
> So these xbuilds are not needed on end-users computers. They are only needed |
| 36 |
to generate the dependance tree. |
| 37 |
|
| 38 |
Well think of xpack files as .tar files but text based for nonbinary content. |
| 39 |
If metadata would be generated from the xbuild files (optional) then that |
| 40 |
metadata would suffice except for the actual compiling/mergin of packages. |
| 41 |
|
| 42 |
> |
| 43 |
> If you need any help on this, please email me. |
| 44 |
|
| 45 |
I'll remember you and surely will ask your help at the point where there's |
| 46 |
something you can do ;-) |
| 47 |
|
| 48 |
Paul |
| 49 |
|
| 50 |
-- |
| 51 |
Paul de Vrieze |
| 52 |
Researcher |
| 53 |
Mail: pauldv@××××××.nl |
| 54 |
Homepage: http://www.devrieze.net |
| 55 |
|
| 56 |
|
| 57 |
|
| 58 |
-- |
| 59 |
Paul de Vrieze |
| 60 |
Researcher |
| 61 |
Mail: pauldv@××××××.nl |
| 62 |
Homepage: http://www.devrieze.net |
| 63 |
|
| 64 |
|
| 65 |
-- |
| 66 |
gentoo-portage-dev@g.o mailing list |
Archives