1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Am 24.03.2011 17:58, schrieb Zac Medico: |
5 |
> Well, it would be inefficient to open separate TCP connections for |
6 |
> individual metadata files since there are so many of them and they are |
7 |
> so small. This is why package managers typically download the metadata |
8 |
> for all packages as a single bundle. For example, see the type of |
9 |
> metadata bundle that is used to implement PORTAGE_BINHOST support: |
10 |
> |
11 |
> http://tinderbox.dev.gentoo.org/default-linux/x86/Packages |
12 |
> |
13 |
|
14 |
Is there a specific reason why the PORTAGE_BINHOST metadata is different |
15 |
from the metadata/cache format? |
16 |
I like the BINHOST metadata better, even if it is split up into several |
17 |
files, because it would already contain the ebuild version it was |
18 |
generated for. Probably it would be a good idea to merge the information |
19 |
of both metadata into a single unified format? |
20 |
|
21 |
This would also solve the problem with the missing version control |
22 |
(described below) as well as simplifying the way portage handles |
23 |
metadata. On the other hand it would be an even more substantial change, |
24 |
which is not necessarily a bad thing. Portage is supposed to work the |
25 |
same way as before – just faster. |
26 |
|
27 |
> It's conceivable that you could simply use rsync to sync the |
28 |
> metadata/cache/ subdirectory from |
29 |
> rsync://rsync.gentoo.org/gentoo-portage/. However, since the rsync tree |
30 |
> constantly mutates and doesn't provide any kind version control, it |
31 |
> would not be very practical to use it in this way. If you fetch the |
32 |
> metadata and the ebuilds separately, you need a way to guarantee that |
33 |
> you can fetch exactly the same revisions of ebuilds that the earlier |
34 |
> fetched metadata corresponds to. |
35 |
-----BEGIN PGP SIGNATURE----- |
36 |
Version: GnuPG v2.0.17 (GNU/Linux) |
37 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
38 |
|
39 |
iEYEARECAAYFAk2PSYAACgkQnzX+Jf4GTUyz7ACcCV44bXSEwoyCg/6uMz8E9/2g |
40 |
c+EAn1m/BpF7rKkSSmpouousupVCbUHL |
41 |
=G4GS |
42 |
-----END PGP SIGNATURE----- |