hi Mark Brown ha scritto: > On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote: > >> The problem was due to a subtle change in zlib1g: in newer versions, the >> compressed output has 0x02 instead of 0x00 at the 10th byte (that is in >> the header). This change occurred somewhere between version 1.2.3-13 and >> 1.2.3.3.dfsg-5 . > > Byte 10 is the XFL field which contains compression method specific > flags. For deflate a value of two indicates that the compressor was > aiming for maximum compression and a value of zero indicates nothing in > particular. The code was previously not bothering to provide any > information about how hard it was trying to compress things. thanks for the explanation (I was too lazy to go look into it myself :-) >> Since dpkg-deb uses zlib1g, this changed the .deb files. So a file >> reconstructed by "debpatch" would be different with the original in 2 >> bytes. > > Two bytes? a .deb file is an "ar" archive containing both a control.tar.gz and a data.tar.gz BTW: let me remind that one goal of debdelta is to obtain "perfect reconstruction". The change in zlib1g did break "perfect reconstruction"; but the reconstructed .deb files were OK in all other respects. >> I have added a workaround for that problem in 'debdelta' version 0.21 , >> and I have installed it in the server that prepares deltas for >> 'debdelta-upgrade' . Now it should work again as expected. (If it does >> not, mail me, or send a bug in the BTS). > > I'm not sure exactly what debdelta is doing here but it sounds like > it ought to have specific code for handing the reconstruction of this > header in order to be robust against reasonable upstream changes. that is what I did. Currently a delta file also saves the header file and then puts it back forcibly. > There > are several fields in there which are informational and could be varied > by the compressor pretty much at will. debdelta relies on the fact that dpkg-deb uses zlib1g to compress control.tar.gz and a data.tar.gz ; so debdelta calls "minigzip", that obtains the same exact result - unless zlib1g changes, of course. "debdelta" currently is not robust w.r.t. strong changes in zlib1g ... the only way to achieve robustness would be that I should ship a copy of the source code of zlib1g inside the debdelta package (but that is inconvenient in other respects). a.
Attachment:
signature.asc
Description: OpenPGP digital signature