[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question: Packages.xz and Contents-<arch>.xz



On Thu, Nov 15, 2012 at 11:57 AM, Neil Williams <codehelp@debian.org> wrote:
> On Thu, 15 Nov 2012 11:10:13 +0900
> Hideki Yamane <henrich@debian.or.jp> wrote:
>>  Just a question, is there any reason not provide Packages.xz and
>>  Contents-<arch>.xz in package repository? I cannot find any information
>>  about it, so please tell me.
>
> A stable release freeze is not the time to go changing stuff like
> this ... all the tools which use and generate the Packages.gz and
> Contents-<arch>.gz files would need support for .xz in place *in
> current stable* before this could be changed permanently.
>
> Does apt have support already?

0.8.10.3+squeeze1 does as its changelog tells us.
Note through that it needs the 'xz' binary for that (as it did for bzip2,
 that changed just yet with the usage of libbz2 now for wheezy and as
 usual people complain about it …). xz is priority required though so
this is most likely not that much of an issue as it was for bzip2.
APT is currently configured to prefer bzip2 over all others though.

All this says nothing about all the other things in the apt-namespace
through and of course nothing about all the other tools working with
files APT happens to use, too, so your mileage may vary.

(For the record, any libapt application using FileFd class can support
 basically every damn compression algorithm in the (un)known universe
 if you can provide a binary and a valid configuration for it since wheezy.
 See: apt-config dump APT::Compressor
 And no, it is not documented, nobody reads documentation anyway)


Note also that it is unlikely that ftpmaster will add another compression
file to the archive and mirror folks will be happy about that. So its not
just a "lets add xz" but a "lets replace bz2 with xz" and this might be
a bit more complicated as indexes like Translation files are only available
in bz2 and this used to be hardcoded everywhere.


Best regards

David Kalnischkies


Reply to: