> Next, to my excuse for subscribing to the list, a question : When I execute > yum-arch after a few files have changed in the RPMS directory, it erases > all old header files and writes new ones. As I then rsync everything to > many locations, it needs to sync the timestamp of all files, and creates > very long listings of actually unchanged files. > So my suggestion would be for yum-arch to have another mode of operation > and try and be more "clever" and only delete obsolete headers and add new > ones, without touching the existing ones, after possibly checking that they > would indeed be identical. > Would that be at all considered? I guess it would be (a bit) more > "expensive", maybe not much, but it would make a difference for me ;-) To explain the expense - it would need to read the header anyway to know that nothing had changed - at which point the read expense is done then it would compare it to the current header, so thats a second read expense, then write the data out to a file or not as need be. so you might save on the write but you'd be doubling the read. In answer to the rsync problem - Axel is right - there is another way to fix it. I'll look back through that thread and maybe pull in the timestamp nulling gzip patch that michael wrote. I can see how that would help people, esp w/rsync. thanks - nice to have you on the list. -sv
