| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Petteri Räty wrote: |
| 5 |
> Zac Medico wrote: |
| 6 |
>> Ciaran McCreesh wrote: |
| 7 |
>>> On Sun, 08 Feb 2009 15:27:54 -0800 |
| 8 |
>>> Zac Medico <zmedico@g.o> wrote: |
| 9 |
>>>>> Which is offset and more by the massive inconvenience of having to |
| 10 |
>>>>> keep track of and store junk under version control. |
| 11 |
>>>> I think you're making it out to be worse than it really is. Like I |
| 12 |
>>>> said, I think we have a justifiable exception to the rule. |
| 13 |
>>> If you start encouraging this approach, are you prepared to make |
| 14 |
>>> Portage warn extremely noisily if a repository-provided (as opposed to |
| 15 |
>>> user generated) cache entry is found to be stale? |
| 16 |
>> Sure. Otherwise, it's confusing for the user when dependency |
| 17 |
>> calculations take longer than usual for no apparent reason. |
| 18 |
>> |
| 19 |
> |
| 20 |
> It would probably be useful to provide a central rsync infra for |
| 21 |
> overlays where overlay maintainers could subscribe their overlays to and |
| 22 |
> the machine would pull in their VCS and generate the metadata for them. |
| 23 |
|
| 24 |
That's fine if somebody wants to implement it. The introduction of |
| 25 |
DIGESTS data in the metadata cache does not preclude it. Like I just |
| 26 |
said in another reply [1], the ability to distribute cache via a vcs |
| 27 |
is only an ancillary feature which is made possible by the DIGESTS data. |
| 28 |
|
| 29 |
[1] |
| 30 |
http://archives.gentoo.org/gentoo-dev/msg_760e199e74796fed7e56236f248efe9e.xml |
| 31 |
- -- |
| 32 |
Thanks, |
| 33 |
Zac |
| 34 |
-----BEGIN PGP SIGNATURE----- |
| 35 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 36 |
|
| 37 |
iEYEARECAAYFAkmQj+UACgkQ/ejvha5XGaOajACePIoV6STCE/bh7SB8X/ch4phk |
| 38 |
bpAAnjsYR9UgBVP26wIldvCX2OFNe4yy |
| 39 |
=kYc/ |
| 40 |
-----END PGP SIGNATURE----- |
Archives