On Mon, 2009-09-14 at 12:30 -0400, Bill Nottingham wrote: > Andreas Schwab (sch...@redhat.com) said: > > > 2. xz generates different compressed files when run on different > > > architectures > > > > The problem is that the encoder uses different hash functions depending > > on the endianess. The hash functions are defined in > > liblzma/lz/lz_encoder_hash.h, and are based on the values in > > lzma_crc32_table[0]. This table is different between big end little > > endian. > > Not having looked at the algorithm... *why*? Is it really that big > of a difference?
Ok, I've just had a conversation on IRC with Lasse Collin, the maintainer of xz. He's now planning on changing xz so it will produce the same output independent of endianess. He hasn't committed to any timeframe, though. He did bring up some other very good points, though. Xz's compression output hasn't been set in sand, much less stone. The file format will stay the same, but the same command-line options may result in different compressed files. We will probably need to have some kind of freeze for xz during a release (or at the very least, a test case added to the build process that fails when a generated xz file doesn't match a precreated one). Alternatives include a mass rebuild whenever xz's compression format changes and/or removing all deltarpms when xz's compression format changes. Another alternative would be for rpm to have a private copy of the xz-lib code that stays fairly static. Not sure how that would go down. So, to summarize, architecture-specific deltarpms are working perfectly in rawhide right now, and, if you're running a PPC machine, all deltarpms are working perfectly. Otherwise, noarch deltarpms will build into an incorrect rpm, and yum-presto will proceed to redownload the full rpm. Jonathan
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
