--hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 20, 2003 at 06:23:11PM +0200, Matthias Saou wrote: > Hi, >=20 > I've made it to the yum list at last :-) > As a very first thing, I got an email from Pieter to this list forwarded = to > me earlier today about a corrupt header.info file on ayo.freshrpms.net... > I've checked and all seems fine. >=20 > Next, to my excuse for subscribing to the list, a question : When I execu= te > 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. Have a look at this thread: https://lists.linux.duke.edu/pipermail/yum/2003-April/001082.html > 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 th= ey > 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 ;-) I think the best solution would be to have the *.hdr inherit the file and gzip timestamp of the parent file. In that case the generated hdr file will always be considered the same by rsync or web caches (same date, same size). I am currently using the null_gzip_ts.py script found in the above thread and something like 'diff new old || mv -f new old' to effectively get something similar. --=20 Axel.Thimm@xxxxxxxxxxxxxxxxxxx --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+8zf8QBVS1GOamfERAlmZAJ9dwaCCjDZS1K9KQm7bD7WLSqi7GwCeOelu iL7LPwTIAYa6oZlcBBS1pck= =0iWQ -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50--
