[Yum] Re: Recreating headers yields different files

[Axel Thimm]

On Tue, Apr 29, 2003 at 09:29:46PM -0400, seth vidal wrote:
> > I wish that yum-arch could do that without a workaround, of course,
> > e.g. timestamping the hdr files (both internally in the gzip header and
> > the file itself) with the timestamp of the originating rpm. yum-arch could
> > even use this to not bother extracting the header out of an rpm, if the
> > corresponding hdr file with the right timestamp exists (the evr is encoded
> > in the name anyway).
> 
> counting on the filename and timestamp to make sure the data inside it
> is right is fairly dangerous. touch -t is just too simple to use and a
> damaged header could be rife with problem causing.

For what it is worth that is the default rsync behaviour. Files with the same
filename-size-timestamp are considered the same. It is possible to turn
checksumming on for these files also, but then rsync becomes a CPU-Monster (on
both sides).

You could even say that that is the way build resolvers work, e.g. make. One
can consider the hdr files being generated by make with a rule %.hdr: %rpm
(simplified, no way to do that with the embedded epoch). In this scenario
changing some rpms would trigger only their header extraction.

Who would use touch -t/-r other than myself or an intruder? In the former
case, I get what I deserve, in the latter I've lost anyway ... :(

> So the next option would be to read and check the header vs the one in
> pkgs. But at that point you'rew doing two hdr reads and other than
> keeping from writing the data out you're not saving yourself anything.
> 
> it's a no fun case. maybe I should include michael's patch.
> 
> <grumble>
> I'll think more about it.

Well, as you pointed out, this is merely a nice-to-have issue. :)

-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.baseurl.org/pipermail/yum/attachments/20030430/7a5b87f8/attachment-0001.pgp