> > <snip>
> >
> > While some hash algorithms do take file modification time into
> > account this is certainly not necessary at all, and in this case a
> > hash algorithm that does not take file modification time into account
> > would definitely be used.
>
> I was talking about modification times saved in the tarball, not the
> modification times of the tarball.
Yes so was I.
> In that case, you would need to
> unpack the package and hash all files in it.
Yes exactly.
"bzcat kdelibs-4.2.0-r1.tbz2 | md5sum" is a trivial example of this.
> But to create a general
> hash algorithm that hashes compressed tar files and does not take into
> account any times and dates is impractical, if not impossible to do it
> so that it makes sense.
It is not even necessary that it runs on the data in its compressed form, it 
can easily decompress files from the archive as it goes and work on the 
uncompressed form, the above trivial sample is already sufficient except for 
the use of md5sum, although there are ways to do this more optimally.
True this is more expensive then a hash of just the tarball itself would be 
but it only needs to be incurred by those who are contributing a package and 
those who are verifying that a contributed package is valid, it does not have 
to be incurred by those actually installing the package, for that a simple 
tarball hash as with source tarballs is sufficient.
Also it certainly does not take long enough that it is impractical.