How is alteration from .gz to .xz going to do anything but create new upgrade or boot issues? what bug number is it? -----------------------------Is lzh/ma xz built already built-in (to kernel or glibs)? What if kernel or libs changes or isn't yet installed? Use bin?
Won't this mean all software and scripts that look into udebs will need to be re-written? Also that udebs will no longer be compatible with dpkg as they were?
Just wondering what the "upgrade" is? ----------------------------------- Bob the Toucan — Copyright © 2005, 2006 Ville Koskinen~ liblzma doesn't include any file I/O functions. A separate I/O library is planned, which would abstract handling of .gz
Below is an incomplete and somewhat vague list of operating systems "most linux""XZ Utils is free general-purpose data compression software with high compression ratio. XZ Utils also work on some not-so-POSIX systems. XZ Utils are the successor ~"
* liblzma is a compression library with API similar to that of zlib.
* xz is a command line tool with syntax similar to that of gzip.
isn't that a 360 while not yet finished ?
Guillem Jover wrote:
On Sat, 2011-11-19 at 17:32:49 -0200, Otavio Salvador wrote:On Sat, Nov 19, 2011 at 17:21, Philipp Kern <pkern@debian.org> wrote:We could start with -z0 of course, which would be supported by dpkg-dev and hence a trivial patch of debhelper would do. But it doesn't gain that much.If you mean dpkg-deb, then as mentioned on the bug report -z0 will switch the compressor to none. The closer thing you can get right now is -z1.Dpkg people, can you comment on that? I've pinged people on IRC already about this bug earlier today.I'm not on IRC anymore. In any case I've been making up my mind over this and playing with some possible options and some draft code, I'll reply to the bug report when I have something more concrete. regards, guillem