Main Inclusion Report for xz-utils

[Scott Kitterman]

Binary package hint: xz-utils

https://wiki.ubuntu.com/MainInclusionXZ-UTILS

Package is needed in main as a build-dep for kde4libs to provide lzma support in KDE. This is particularly relevant for KDE since all KDE packages are lzma compressed and it's useful for Kubuntu devs to be able to use their own tools with these .debs.

[Kees Cook (kees)]

This is a binary-data compression system, for which security bugs have traditionally been common. Is there a reason this library is being used instead of lzma-dev? I would prefer to have a single lzma library in main, not two.

[Scott Kitterman (kitterman)]

This is the library that upstream chose to support. lzma-dev doesn't work and we would have to both port this and maintain the port. The Kubuntu team does not have the resources/expertise to do this. We can commit to discussing this with upstream for a future release, but really can't solve this on our own.

Since we are using lzma in all the KDE debs this is an important feature for Kubuntu.

[Kees Cook (kees)]

Since this is a fork of the "lzma" package, and since xz-utils provides/replaces the "lzma" binary package, I think it is only sensible to choose between xz-utils and lzma. Currently building against stuff from the "lzma" source package are:

Package: cacao-oj6
Package: eglibc
Package: gcc-4.2
Package: gcc-4.3
Package: gcc-4.4
Package: gcc-snapshot
Package: gcj-4.2
Package: gcj-4.3
Package: gcj-4.4
Package: gdc-4.2
Package: glibc
Package: gnat-4.2
Package: gnat-4.3
Package: gnat-4.4
Package: kdeutils
Package: openjdk-6
Package: squashfs

It looks like kdeutils already uses lzma-dev, so this just re-enforces the point.

[Loïc Minier (lool)]

I think xz is planned to replace lzma completely over time; it's also kind of chicken and egg: if we want to make kdelibs bdep on xz instead of lzma we need to promote it to main.

I personally am fine with replacing lzma with xz, but we need a fully fledged transition.

[Scott Kitterman (kitterman)]

I think it's far to close to feature freeze to do a complete transition in Karmic. I'm testing with lzma-dev to see if I can make that work for KDE.

[Harald Sitter (apachelogger)]

Well, kdeutils should not have had a build-dep on lzma, since it uses xz nowadays as well.

Also, from a quick look at the headers in lzma-dev it appears to me that stuff created against xz is not compatible, like not at all. So there is no way to get kdelibs to build against lzma-dev without rewriting the whole KDE compression filter for it.

So, either we transit to xz (which is not too much of a good idea due to the beta state of it, probably) or KDE does not have lzma support until xz replaces lzma.
I also need to mention that xz is not a fork, but a super enhanced version of lzma which was original lzma-utils 5

[Martin Pitt (pitti)]

Embrace and extend at its finest :-(

Kees, do we have a place to track duplication of security sensitive libraries, such as http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file, where this could be added, if this gets approved?

compression APIs are usually very small, you usually just have some 5 methods. Do you have an estimate how much effort it would be to rewrite those small parts to use liblzma-dev?

[Kees Cook (kees)]

pitti: yup, I'd already added it to e-c-c:
http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=diff&rev=12584&sc=0

So, after more review and limited discussion with Debian upstream, I'll approve this for karmic with an interest to revisiting it for karmic+1 in the hopes of solving the duplicated code. It seems that xz-utils provides additional features above lzma, and is an active project.

[Martin Pitt (pitti)]

Promoted