1 |
> do you think end-users need all ebuilds ? I have a laptop, and fetching |
2 |
> the whole portage tree doesn't make any sence, since I emerge only a few |
3 |
> apps. On the other hand, I'd like to fetch a "pre-computed" cache or |
4 |
> world file, and fetch only ebuilds when necessary (emerging a package |
5 |
> for example). Those "emerge rsync" are way too long, and can be |
6 |
> drasticly reducted using a different way of thinking. |
7 |
> |
8 |
> Of course, the whole portage tree could be installed, as it is in FreeBSD ;) |
9 |
|
10 |
You're right, they probably don't. My system will be quite modular and I image |
11 |
a new tree, maybe I'll implement it in the initial release. One concept I'm |
12 |
thinking about is something I call xpack (where xbuild is the extension of |
13 |
ebuilds that should be guaranteed to work with the new parser). This basically |
14 |
is a text based packaging format (like tar, but actually diffeable), that |
15 |
would contain all parts needed for an ebuild (source is optional). Such a file |
16 |
would make things a lot easier to manage and to download on demand. |
17 |
|
18 |
While my main focus will not be on ondemand downloading of xpacks (ebuilds is |
19 |
pointless) it should be fairly trivial to generate metadata files for the |
20 |
packages contained, maybe even on a category level. The transfer size could |
21 |
still be sizeable though. I believe that introduction of xpack files |
22 |
containing everything needed for an ebuild (except the manifest and |
23 |
metadata.xml) allready reduces the amount of files in the tree enormously. It |
24 |
also helps in being able to easilly remove unused patches ;-). |
25 |
|
26 |
Paul |
27 |
|
28 |
-- |
29 |
Paul de Vrieze |
30 |
Gentoo Developer |
31 |
Mail: pauldv@g.o |
32 |
Homepage: http://www.devrieze.net |
33 |
|
34 |
|
35 |
-- |
36 |
gentoo-portage-dev@g.o mailing list |