1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Zac Medico wrote: |
5 |
> Emma Strubell wrote: |
6 |
>> And to clarify: the goal of the project is to modify portage so that |
7 |
>> instead of fetching all of the ebuilds in the portage tree (or in an |
8 |
>> overlay) upon a sync, portage only fetches the metadata and cache info |
9 |
>> (via the metadata/cache/ directory) of the tree, and the ebuilds of |
10 |
>> packages that are already installed (packages found in the world |
11 |
>> file?) And then, additional ebuilds would be fetched only when they |
12 |
>> are needed? |
13 |
> |
14 |
> The problem with fetching the ebuilds separately is that the remote |
15 |
> repository might have changed. So, it's not a very reliable approach |
16 |
> unless there is some kind of guarantee that the remote repository |
17 |
> will provide a window of time during which older ebuilds that have |
18 |
> already been removed from the main tree can still be downloaded. In |
19 |
> order to accomplish this, you'd essentially have to devise a new |
20 |
> source package format which can be downloaded as a single file |
21 |
> (something like a source rpm file that an rpm based distro would |
22 |
> provide). |
23 |
|
24 |
Expanding on this a bit... if you were going to pack an ebuild into |
25 |
a single file, you would need to include the eclasses which it |
26 |
inherits and also any patches that are included with it in cvs. If |
27 |
the eclasses are included in this way, each source package will |
28 |
contain a redundant copy of the inherited eclasses. Despite this |
29 |
redundancy, you might still have a net decrease in bandwidth usage |
30 |
since you'd only have to download the source packages that you |
31 |
actually want to build. |
32 |
|
33 |
If you are going to implement something like this, I imagine that |
34 |
you'd create a tool which would pack an ebuild into a source package |
35 |
and optionally sign it with a digital signature. Source packages |
36 |
would be uploaded to a server which would serve them along with a |
37 |
metadata cache file that clients would download for use in |
38 |
dependency calculations (similar to how $PKGDIR/Packages is |
39 |
currently used for binary packages). |
40 |
- -- |
41 |
Thanks, |
42 |
Zac |
43 |
-----BEGIN PGP SIGNATURE----- |
44 |
Version: GnuPG v2.0.11 (GNU/Linux) |
45 |
|
46 |
iEYEARECAAYFAknUT0oACgkQ/ejvha5XGaPmugCfVs0I4a15trwTgLnPwBac2xOj |
47 |
wI0AoInp1Jf6yaYV5rNvU2EXHbZ30AkS |
48 |
=tNrz |
49 |
-----END PGP SIGNATURE----- |