1 |
Hola all, |
2 |
Straight to the point, I propose instead of md5summing the compressed |
3 |
distfile, we md5sum the actual data, the tarball. There are a couple of |
4 |
reasons/benefits of this- |
5 |
|
6 |
1) users are currently tied to a specific compression on the tarball- |
7 |
for those who would want to convert their distfiles to bzip2 rather then |
8 |
gzip (for space reasons), they're a bit out of luck- yes, they can |
9 |
attempt to update md5sum digests or force it to ignore the incorrect |
10 |
sums, but that gets old *real* quick. |
11 |
|
12 |
2) Say for whatever reason, the tarball gets inflated- if the original |
13 |
tarball was compressed w/ say bzip2 0.90, and the user has bzip2 1.x, |
14 |
even if they recompress it they're out of luck- the bzip2 algorithm was |
15 |
tweaked for better compression after .90, resulting in a different |
16 |
md5sum then the original. Yet the distfile is still data-correct- it's |
17 |
just compressed slightly differently. |
18 |
|
19 |
3) For anyone making a serious attempt at distfile diffs, the |
20 |
reconstruction process is seriously borked by the possibility that it's |
21 |
data-correct, but the compression has changed/been improved resulting in |
22 |
a different md5sum. I do know JJW's deltup attempt ran smack dab into |
23 |
this problem w/ the openoffice tarballs. I've also ran into the |
24 |
problem, and I'd prefer not to use the deltup method of having both old |
25 |
bzip2 and current bzip2 installed. |
26 |
|
27 |
In terms of performance of the md5summing, it would still likely be i/o |
28 |
limited- decompression would be done in memory after all. |
29 |
That said and done, I'm not after bludgeoning someone into implementing |
30 |
this- assuming people don't have any major criticism's against it and it |
31 |
has more then a snowball's chance in hell of being used I'm more then |
32 |
willing to code it myself. |
33 |
Comments/Flames/Death Threats? |
34 |
~Brian |
35 |
|
36 |
|
37 |
-- |
38 |
gentoo-dev@g.o mailing list |