| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
tvali schrieb: |
| 5 |
> But about filesystem... |
| 6 |
> |
| 7 |
> [... snip lots of stuff ...] |
| 8 |
|
| 9 |
What you mentioned for the filesystem might be a nice thing (actually I |
| 10 |
started something like this some time ago [1] , though it is now dead |
| 11 |
;)), but it does not help in the index/determine changes thing. It is |
| 12 |
just another API :). |
| 13 |
|
| 14 |
Perhaps the "index after sync" is sufficient for most parts of the |
| 15 |
userbase - but esp. those who often deal with their own local overlays |
| 16 |
(like me) do not want to have to re-index manually - esp. if re-indexing |
| 17 |
takes a long time. The best solution would be to have portage find a) |
| 18 |
THAT something has been changed and b) WHAT has been changed. So that it |
| 19 |
only has to update these parts of the index, and thus do not be sth |
| 20 |
enerving for the users (remind the "Generate Metadata" stuff (or |
| 21 |
whatever it was called) in older portage versions, which alone seemed to |
| 22 |
take longer than the rest of the sync progress) |
| 23 |
|
| 24 |
Regards, |
| 25 |
René |
| 26 |
|
| 27 |
[1] https://launchpad.net/catapultfs |
| 28 |
-----BEGIN PGP SIGNATURE----- |
| 29 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 30 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 31 |
|
| 32 |
iEYEARECAAYFAkkqxSsACgkQ4UOg/zhYFuBPSACdH9H6VChrhlcovucgVAcCsp/B |
| 33 |
j+AAmgPXPmuBs5GWnNAfs5nss4HlBEMT |
| 34 |
=WG8B |
| 35 |
-----END PGP SIGNATURE----- |
Archives