| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
|
| 5 |
On Apr 11, 2004, at 3:22 PM, Paul de Vrieze wrote: |
| 6 |
|
| 7 |
> On Sun, 11 Apr 2004, Brian Harring wrote: |
| 8 |
> |
| 9 |
>> I pestered a few people to get some additional stats for bolstering |
| 10 |
>> the |
| 11 |
>> reason for using an alternate md5 db; it truly is painful to have to |
| 12 |
>> decompress then md5sum that data for users w/ lower end systems- |
| 13 |
>> |
| 14 |
> That is quite expectable, however what about only using the |
| 15 |
> uncompressed |
| 16 |
> md5 either when the compressed md5 doesn't fit (and it is reassembled) |
| 17 |
Reconstruction of the file is a one time thing, done when the patches |
| 18 |
are pulled down initially- as for doing uncompressed md5 only when the |
| 19 |
md5 in the tree doesn't match, yep, granted. |
| 20 |
> or |
| 21 |
> as a filter between the untar and the uncompress step. |
| 22 |
Untar/decompress step? Guessing you're referencing when the ebuild |
| 23 |
calls unpack? If so, a few issues. |
| 24 |
All verification of distfiles takes place in portage.py, so either A) a |
| 25 |
mechanism would have to be implemented to feed the md5 sum back to |
| 26 |
portage (not fun), or B) ebuild.sh would have to be able to make a |
| 27 |
determination if the md5 sums matched. |
| 28 |
Bit unclear on what you're stating above, could you elaborate? |
| 29 |
~brian |
| 30 |
-----BEGIN PGP SIGNATURE----- |
| 31 |
Version: GnuPG v1.2.4 (Darwin) |
| 32 |
|
| 33 |
iD8DBQFAegtcvdBxRoA3VU0RAjRWAJsGl/8KnKWNCp97eDc2lSdyQXrf2wCgg46r |
| 34 |
7FFNTKPHDHd51h2rw6Dnp9I= |
| 35 |
=URdx |
| 36 |
-----END PGP SIGNATURE----- |
| 37 |
|
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-dev@g.o mailing list |
Archives