Hi! Switching the support from lzma to xz has been on my radar for some time, but given that the tools and library in unstable didn't seem to be ready, and the ones which seemed to were in experimental, I had not yet looked into writting the code.
I'm also leaving for the weekend so I'll review your pacthes when I come back, there's some issues from skimming fast over them. On Tue, 2009-08-18 at 02:55:25 -0500, Jonathan Nieder wrote: > Raphael Hertzog wrote: > > > * Some users may want to install XZ Utils without the legacy commands > > > (by installing xz-utils but not xz-lzma nor lzma). dpkg should still > > > work for such users. Last time I checked the xz-utils package was too big, it would be nice to move away devel documentation into the development package for example. > > Why would it not work? > > xz-utils does not include /usr/bin/lzma (though xz-lzma does). > > > Do you have a plan to remove the current lzma > > source package? > > No, I’d rather not see it disappear soon if that can be helped. > > >> * Without this change, switching between lzma and xz-lzma is > >> impossible, since it requires being without the pseudo-essential > >> package lzma for a few moments. With this change, switching between > >> lzma and xz-lzma would work fine as long as xz-utils is installed. > > > > What would you put in the Pre-Depends field to ensure this? lzma | > > xz-utils | xz-lzma ? > > I’d just put lzma | xz-utils. The /usr/bin/lzma included in xz-lzma is > just a symlink to xz from xz-utils, and dpkg would use xz directly if > available. For the lzma binary I'd rather leave it as it is. So either use the lzma binary from its package or the compat symlink from xz-utils if available. Given that we'd be using the library it does not matter as the binary call will be disabled. > > Other questions: > > - instead of replacing current lzma support, wouldn't it be more > > interesting to add full xz support? As I understand it, the format > > evolved/improved and it would be interesting for dpkg to be able to use > > it (and not only the old lzma one). > > Yes, filed as a separate bug (I think the patch for it will be simpler > :). See Bug#542160. Right, that has been my plan, support both via the library, but probably warn on creation of lzma compressed archives, althought lzma is the only that could be used right now as it's supported in stable, but then the archive still rejects them. So the warning could be postponed. > > - do you have a libxz that can be used instead of requiring the command > > line interface? if no, is one planned in the future? > > Yes, liblzma supports both .lzma and .xz files. But wasn’t there > discussion before about preferring to spawn another process when > decompressing files? This doesn’t preclude using a library, but it > diminishes the benefits. > > On the other hand, linking dpkg to a static library would simplify > dependencies quite a bit, so it sounds pretty tempting to me. No, the preferred way is linking against a library, which already forks to do the processing. It would also mean that one library can handle both formats, and we don't need to care about different binaries. Also the fact that we are linking statically will have to be changed anyway, it has some merits but it makes other things more difficult, it will also be a problem with the future libdpkg anyway. I'll be proposing this to the list once I'm back. > > PS: Next time please just put patches as attachment in a single mail > > instead of mailing them separately. > > Thanks for the tip. Is there a file somewhere with guidelines for > contributing to dpkg? Some projects’ STANDARDS or SubmittingPatches > files seem to be very useful for learning this sort of conventions. I've been meaning to write one! thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
