| 1 |
> Not neccesarilly... Open connection; fetch pkgiwant; check deps; |
| 2 |
> fetch depineed; no more deps: Close connection |
| 3 |
> Determining dependencies should be fast enough to keep the |
| 4 |
> connection open for. |
| 5 |
|
| 6 |
Sure... But would only require internal handling of web/ftp |
| 7 |
protocols and rewriting emerge and/or doing single-dep parsing |
| 8 |
for each entry... AND now that you're removed wget, you have to |
| 9 |
maintain the file-states manually. That's a LOT of code with |
| 10 |
LOTS of room for bugs. If someone feels up to handling all of |
| 11 |
this, they can feel free to try and get it right. |
| 12 |
|
| 13 |
It's a matter of sanity. From a programming and support |
| 14 |
aspect, I'm not interested in non-consistent states. I |
| 15 |
highly doubt this would be supported by dev-portage in any |
| 16 |
reasonably near future as there are more important things |
| 17 |
to be concerned with. It might also introduce difficulties |
| 18 |
in modifying the structure of the tree later. |
| 19 |
|
| 20 |
> How so? Fetch checksums too. And the purpose of such an |
| 21 |
> ability would be to make sync-updates unneccesary. |
| 22 |
|
| 23 |
Data gets corrupted. |
| 24 |
|
| 25 |
Checksums of all data in the tree would be unnecessary |
| 26 |
duplication of the existing system's capabilities. Why change |
| 27 |
if you're simply going to reimplement everything? |
| 28 |
|
| 29 |
GPG will introduce some of the at-sync checking of digests and |
| 30 |
Manifests, but you _really_ don't want to experience the full |
| 31 |
cost of verifying every file like this. It's already painful |
| 32 |
with just manifest checking. (Hopefully, we'll get that sped |
| 33 |
up though. Might have to write a lib for gpg.) |
| 34 |
|
| 35 |
--NJ |
Archives