Switching default dpkg-deb compressor to xz

[Guillem Jover]

Hi!

As mentioned some months ago [0], I'm planning to switch dpkg-deb default
compressor from gzip to xz, as there seemed to be consensus that was
the way to go, and given the amount of already manually switched
packages, or packaging helpers. :/

[0] <http://lists.debian.org/debian-devel/2012/08/msg00822.html>

The only previous dissenting argument was that the base system (the
one generated by debootstrap), should keep using gz as the compression
format so that it can work on other systems where xz is not easily
available. But Steve McIntyre then mentioned that even that had
changed during DebConf and it was not deemed worth it. I don't mind
either way.

If there's people who are still worried about that, I'd ask them to
file bugs on the base packages to make them pass -Zgz explicitly to
dpkg-deb (I'll do that for dpkg.deb in any case), and I can wait for
the base system to be switched, but those packages could always be
changed on their next upload, or even a fatal lintian error created
so that ftp-master can reject those (I don't think there's one
currently?). Otherwise I'll be doing the change with the dpkg 1.17.0
upload.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130507194...@gaara.hadrons.org

[Raphael Hertzog]

Hi,

On Tue, 07 May 2013, Guillem Jover wrote:
> As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> compressor from gzip to xz, as there seemed to be consensus that was
> the way to go, and given the amount of already manually switched
> packages, or packaging helpers. :/

[...]

> currently?). Otherwise I'll be doing the change with the dpkg 1.17.0
> upload.

I agree that we have such a consensus.

There was a time where d-i was not ready, but nowadays udeb are compressed
with xz and busybox's xz is used in that context.

Please go ahead with this change (unless some other valid concerns are
raised that is).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130508084...@x230-buxy.home.ouaza.com

[Dmitrijs Ledkovs]

On 8 May 2013 01:46, Raphael Hertzog <her...@debian.org> wrote:
> Hi,
>
> On Tue, 07 May 2013, Guillem Jover wrote:
>> As mentioned some months ago [0], I'm planning to switch dpkg-deb default
>> compressor from gzip to xz, as there seemed to be consensus that was
>> the way to go, and given the amount of already manually switched
>> packages, or packaging helpers. :/
> [...]
>> currently?). Otherwise I'll be doing the change with the dpkg 1.17.0
>> upload.
>
> I agree that we have such a consensus.
>
> There was a time where d-i was not ready, but nowadays udeb are compressed
> with xz and busybox's xz is used in that context.
>
> Please go ahead with this change (unless some other valid concerns are
> raised that is).
>

A while back I have raised a proposal on debian-devel, to include a
facility to opt-out of compressing packages. As a DEB_BUILD_OPTIONS
for example or via some other mechanism. Personally I have seen a
great build-time reduction, whilst doing test builds (or "slow" builds
on arm panda board / qemu), or whist doing a noopt & nostrip builds as
all of these builds are usually local and one may just one to have
the package simply sooner.

I have spotted an independent implementation in an ubuntu's
pkg-kde-tools (not sure if it's in debian one as well, at least it's
not in the experimental upload) that defaults to xz, yet honours
DEB_NO_XZ and DEB_NO_COMPRESSION environmental variables to disable
such compression.

Thinking more generically than last time around, would it be ok to
propose ability to set / override dpkg-deb compression options via
DEB_BUILD_OPTIONS? It would greatly simply rebuilding with no
compression / alternative algos and settings. In particular it will
ease to identify packages that do _not_ benefit from additional
compression and/or perform better under non-default compression
setting. I'm thinking of infamous openclipart, the one that has all
images pre-compressed and a couple dozen of other similar packages.

Should I open a bug and propose a change to debian-policy? Or do we
need to bikeshed more about this?

Last time around there was no significant arguments to not have such a facility.

Regards,

Dmitrijs.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CANBHLUjmD9Cf07Lm_WnioQnhJgAFUn_cOGqYGa6t-Ct5J=bL...@mail.gmail.com

[Ansgar Burchardt]

Hi,

On 05/07/2013 21:49, Guillem Jover wrote:
> As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> compressor from gzip to xz, as there seemed to be consensus that was
> the way to go, and given the amount of already manually switched
> packages, or packaging helpers. :/
>
> [0] <http://lists.debian.org/debian-devel/2012/08/msg00822.html>

Do you plan to switch the default compression for source packages to xz
as well?

Ansgar

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/518A1833...@debian.org

[Adam Borowski]

On Wed, May 08, 2013 at 11:17:39AM +0200, Ansgar Burchardt wrote:
> Hi,
>
> On 05/07/2013 21:49, Guillem Jover wrote:
> > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > compressor from gzip to xz, as there seemed to be consensus that was
> > the way to go, and given the amount of already manually switched
> > packages, or packaging helpers. :/
> >
> > [0] <http://lists.debian.org/debian-devel/2012/08/msg00822.html>
>
> Do you plan to switch the default compression for source packages to xz
> as well?

Would be great -- as opposed to ancient xz-less systems that can be an issue
for debootstrap, source packages are always safe. If you backport to a
version of Debian that old, you're deep in recursive backport land anyway
and having one more tool to backport isn't a hurdle.

--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130508100...@angband.pl

[Philipp Kern]

On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote:
> If there's people who are still worried about that, I'd ask them to
> file bugs on the base packages to make them pass -Zgz explicitly to
> dpkg-deb (I'll do that for dpkg.deb in any case), and I can wait for
> the base system to be switched, but those packages could always be
> changed on their next upload, or even a fatal lintian error created
> so that ftp-master can reject those (I don't think there's one
> currently?). Otherwise I'll be doing the change with the dpkg 1.17.0
> upload.

The problem with that check was that it's hard to determine what's in the
base set as that's defined by the essential packages plus their (transitive)
dependencies. So it'd need to be either a static list or something more
clever that looks at the target suite. (And even then another binary might
suddenly be depended on which is not xz-compressed.)

That only matters iff we care about the base system needing to be
gz-compressed.

Kind regards
Philipp Kern

[Guillem Jover]

Hi!

On Wed, 2013-05-08 at 12:03:13 +0200, Adam Borowski wrote:
> On Wed, May 08, 2013 at 11:17:39AM +0200, Ansgar Burchardt wrote:
> > On 05/07/2013 21:49, Guillem Jover wrote:
> > > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > > compressor from gzip to xz, as there seemed to be consensus that was
> > > the way to go, and given the amount of already manually switched
> > > packages, or packaging helpers. :/
> > >
> > > [0] <http://lists.debian.org/debian-devel/2012/08/msg00822.html>
> >
> > Do you plan to switch the default compression for source packages to xz
> > as well?

I've not proposed this for now, because I don't think we've discussed
it previously. But I'm happy to do the switch for V2+ formats (not for
V1) at the same time (or during the dpkg 1.17.x cycle) if there's also
consensus for it.

> Would be great -- as opposed to ancient xz-less systems that can be an issue
> for debootstrap, source packages are always safe. If you backport to a
> version of Debian that old, you're deep in recursive backport land anyway
> and having one more tool to backport isn't a hurdle.

Right.

Thanks,
Guillem

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013050811...@gaara.hadrons.org

[Guillem Jover]

On Wed, 2013-05-08 at 12:38:47 +0200, Philipp Kern wrote:
> On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote:
> > If there's people who are still worried about that, I'd ask them to
> > file bugs on the base packages to make them pass -Zgz explicitly to
> > dpkg-deb (I'll do that for dpkg.deb in any case), and I can wait for
> > the base system to be switched, but those packages could always be
> > changed on their next upload, or even a fatal lintian error created
> > so that ftp-master can reject those (I don't think there's one
> > currently?). Otherwise I'll be doing the change with the dpkg 1.17.0
> > upload.
>
> The problem with that check was that it's hard to determine what's in the
> base set as that's defined by the essential packages plus their (transitive)
> dependencies. So it'd need to be either a static list or something more
> clever that looks at the target suite. (And even then another binary might
> suddenly be depended on which is not xz-compressed.)

In theory, as long as the Priority fields are kept up-to-date in the
archive, then that should be a matter of just checking if a packages
is required or important, which also implies the lintian check would
not be much useful as the .deb Priority does not need to match the one
in the archive. That does not solve the additional dependencies, but
usually adding to the base system implies a discussion on debian-devel,
or automated sanity checks could be performed from time to time.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013050811...@gaara.hadrons.org

[Michael Banck]

Hi,

On Wed, May 08, 2013 at 11:17:39AM +0200, Ansgar Burchardt wrote:

> On 05/07/2013 21:49, Guillem Jover wrote:
> > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > compressor from gzip to xz, as there seemed to be consensus that was
> > the way to go, and given the amount of already manually switched
> > packages, or packaging helpers. :/
> >
> > [0] <http://lists.debian.org/debian-devel/2012/08/msg00822.html>
>
> Do you plan to switch the default compression for source packages to xz
> as well?

You mean for debian.tar? I would assume most debian.tars are not so big
that it would make a big difference and be worth the hassle, but dunno.


Michael

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013050815...@nighthawk.chemicalconnection.dyndns.org

[Bastian Blank]

On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote:

> As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> compressor from gzip to xz, as there seemed to be consensus that was
> the way to go, and given the amount of already manually switched
> packages, or packaging helpers. :/

What about the compression level? xz -6 is pretty heavy and not needed
for 99% of the packages. -3 or even -2 or -1 are sufficient.

Bastian

--
Youth doesn't excuse everything.
-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
stardate 5928.5.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130508161...@waldi.eu.org

[Joey Hess]

Raphael Hertzog wrote:
> I agree that we have such a consensus.

Not for packages installed by debootstrap.

> There was a time where d-i was not ready, but nowadays udeb are compressed
> with xz and busybox's xz is used in that context.

That's not relevant.

--
see shy jo

[Raphael Hertzog]

On Wed, 08 May 2013, Michael Banck wrote:
> > Do you plan to switch the default compression for source packages to xz
> > as well?
>
> You mean for debian.tar?

This and "3.0 (native)" source packages.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130508164...@x230-buxy.home.ouaza.com

[Adam Borowski]

On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote:
> On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote:
> > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > compressor from gzip to xz, as there seemed to be consensus that was
> > the way to go, and given the amount of already manually switched
> > packages, or packaging helpers. :/
>
> What about the compression level? xz -6 is pretty heavy and not needed
> for 99% of the packages. -3 or even -2 or -1 are sufficient.

As my and Hideki's repacks of the archive show, special-casing small
packages is a waste of time: gains are hardly below linear for any
packages big enough to take longer than fork()ing the compressor.

Quoting some data from 2011, all with xz -6:
] * A repack of the whole archive (amd64+all main, ~40GB) took close to three
] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz).
]
] Does someone have an estimate how many core-hours would an archive rebuild
] on such a machine take? Folks on IRC quoted numbers like "340", "240 on a
] very fast box", "more like 1500" -- too divergent for my liking. The
] first number, 340, would mean switching to xz exclusively would increase
] average build time by ~5%.
]
] * armel Cortex-A8 600MHz does xz consistently 12.1 times slower than one
] core of the above box (on a big compressible and a big uncompressible
] file), that's ~2.6 times slower per-MHz.
]
] Glancing at build logs of a few randomly chosen packages, I see armel
] builds taking respectively 16.9, 13.1, 18.8 and 15.1 times longer. Not
] sure what are the actual speeds of buildds, but it looks like armel would
] be affected by less than the above 5%.

I'd thus suggest using the default, -6, everywhere other than perhaps
openclipart (already compressed) and the likes. xz folks chose this value
for a reason :)

--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013050821...@angband.pl

[Bastian Blank]

On Wed, May 08, 2013 at 11:13:59PM +0200, Adam Borowski wrote:
> On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote:
> > On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote:
> > > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > > compressor from gzip to xz, as there seemed to be consensus that was
> > > the way to go, and given the amount of already manually switched
> > > packages, or packaging helpers. :/
> >
> > What about the compression level? xz -6 is pretty heavy and not needed
> > for 99% of the packages. -3 or even -2 or -1 are sufficient.

> As my and Hideki's repacks of the archive show, special-casing small
> packages is a waste of time: gains are hardly below linear for any
> packages big enough to take longer than fork()ing the compressor.

dpkg-deb does not fork the xz:
| $ objdump -x /usr/bin/dpkg-deb | grep liblzma
| NEEDED liblzma.so.5

> Quoting some data from 2011, all with xz -6:
> ] * A repack of the whole archive (amd64+all main, ~40GB) took close to three
> ] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz).

This doesn't add up to the numbers I have from real life packages.
linux-image-*-amd64-dbg, compressed size 250MiB, takes 20-30 minutes to
compress on an 61xx Opteron.

> I'd thus suggest using the default, -6, everywhere other than perhaps
> openclipart (already compressed) and the likes. xz folks chose this value
> for a reason :)

What is the advantage of -6 over -1? How much better is it? How much
less time does it need? How much memory does it need?

Bastian

--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130508224...@waldi.eu.org

[Ben Hutchings]

On Thu, 2013-05-09 at 00:42 +0200, Bastian Blank wrote:
> On Wed, May 08, 2013 at 11:13:59PM +0200, Adam Borowski wrote:
> > On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote:
> > > On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote:
> > > > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > > > compressor from gzip to xz, as there seemed to be consensus that was
> > > > the way to go, and given the amount of already manually switched
> > > > packages, or packaging helpers. :/
> > >
> > > What about the compression level? xz -6 is pretty heavy and not needed
> > > for 99% of the packages. -3 or even -2 or -1 are sufficient.
>
> > As my and Hideki's repacks of the archive show, special-casing small
> > packages is a waste of time: gains are hardly below linear for any
> > packages big enough to take longer than fork()ing the compressor.
>
> dpkg-deb does not fork the xz:
> | $ objdump -x /usr/bin/dpkg-deb | grep liblzma
> | NEEDED liblzma.so.5
>
> > Quoting some data from 2011, all with xz -6:
> > ] * A repack of the whole archive (amd64+all main, ~40GB) took close to three
> > ] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz).
>
> This doesn't add up to the numbers I have from real life packages.
> linux-image-*-amd64-dbg, compressed size 250MiB, takes 20-30 minutes to
> compress on an 61xx Opteron.

[...]

Yes, it takes about as long as the compilation (depending on number of
cores) because compression is not parallelised. It still seems
worthwhile when the debug info is so large, but I would like to see dpkg
use a parallelised xz compressor when the parallel option is present in
DEB_BUILD_OPTIONS.

Ben.

--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

[Hideki Yamane]

On Wed, 8 May 2013 17:57:57 +0200
Michael Banck <mba...@debian.org> wrote:
> You mean for debian.tar? I would assume most debian.tars are not so big
> that it would make a big difference and be worth the hassle, but dunno.

Yes, not a big difference for debian.tar as blogged(*),
- gz : 503M
- xz : 414M


*) http://henrich-on-debian.blogspot.jp/2013/04/re-compress-debiantargzbz2.html


--
Regards,

Hideki Yamane henrich @ debian.or.jp/org
http://wiki.debian.org/HidekiYamane

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130513140945.39df...@debian.or.jp

[John D. Hendrickson and Sara Darnell]

I'm complaining.

Why are you fixing something that isn't broken and isn't an issue ?
Are you trying to cause problems with free software?
Are you playing favorites?
It's too new to say if it has no long term problems (ie, such as
support issues).

How is shipping (ie kernel) in all three of .gz, and .bz2,
and in .xz saving anyone on either size any time or effort?
It isn't.

I still think Compress is all the rage and the best of
end all solutions :)

Guillem Jover wrote:
> Hi!
>
> As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> compressor from gzip to xz, as there seemed to be consensus that was

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/5191990F...@cox.net

[Ben Hutchings]

On Mon, 2013-05-13 at 21:53 -0400, John D. Hendrickson and Sara Darnell
wrote:

> I'm complaining.
>
> Why are you fixing something that isn't broken and isn't an issue ?

It's not broken, but there is an issue: it's getting hard to fit a
generally useful set of packages and tasks on CD#1, and xz compression
would make this easier. In general, xz can achieve substantially better
compression ratios than gzip, with little extra cost in decompression
time.

> Are you trying to cause problems with free software?
> Are you playing favorites?

What basis do you have for making such accusations?

> It's too new to say if it has no long term problems (ie, such as
> support issues).

xz has been supported in Debian for some time, with no problems that I'm
aware of.

> How is shipping (ie kernel) in all three of .gz, and .bz2,
> and in .xz saving anyone on either size any time or effort?
> It isn't.

Er... kernel.org does that, not Debian.

Ben.

> I still think Compress is all the rage and the best of
> end all solutions :)
>
>
> Guillem Jover wrote:
> > Hi!
> >
> > As mentioned some months ago [0], I'm planning to switch dpkg-deb default
> > compressor from gzip to xz, as there seemed to be consensus that was
>
>

--

Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1368500308.4...@deadeye.wl.decadent.org.uk

[Russ Allbery]

Ben Hutchings <b...@decadent.org.uk> writes:
> John D. Hendrickson and Sara Darnell wrote:

>> It's too new to say if it has no long term problems (ie, such as
>> support issues).

> xz has been supported in Debian for some time, with no problems that I'm
> aware of.

It's also being widely adopted by upstreams and is now (moderately)
encouraged by the GNU autotools for distributions, although a lot of more
conservative GNU projects continue to use gzip. However, at least one of
the gzip maintainers has encouraged people switch to xz and believes it's
less likely to have security issues. (Apparently the gzip code isn't
structured horribly well.)

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87mwryc...@windlord.stanford.edu

[Sune Vuorela]

On 2013-05-14, John D. Hendrickson and Sara Darnell <johnan...@cox.net> wrote:
> Are you trying to cause problems with free software?

Quite the opposite. He is trying to ensure that we don't have to modify
all packages to get them xz compressed, but rather does it from a
central place.

/Sune

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/slrnkp3rfc...@sshway.ssh.pusling.com

[John D. Hendrickson and Sara Darnell]

Ben what basis do you have against .gz ?

And I'd love to know if it won't cause dependancy problems when
someone has more than one debian they are dealing with.

I doubt it's as simple as stated.

What's wrong with saying so?

And yes I do think there are some that would inject problems (such as
killing init for a new startup that isn't compatible).

There are all kinds of proposals continually that are unwise. And
this one has been complained against and re-submitted often already.

So why shouldn't I repeat past complaints others have made on previous
posts.

I think your singling me out.

To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/5192A43B...@cox.net

[John Paul Adrian Glaubitz]

On 05/14/2013 10:53 PM, John D. Hendrickson and Sara Darnell wrote:
>
> Ben what basis do you have against .gz ?

It was already mentioned, it takes more space. Everyone (e.g. Fedora
with rpm) is switching to xz, not just Debian. The Linux kernel is using
more advanced compression algorithms as well.

What problem are you having with xz?

> And I'd love to know if it won't cause dependancy problems when someone
> has more than one debian they are dealing with.

Yes, of course, we need to support every single configuration and every
possible choice of preferred software again, meaning we are doomed to
stick to old stuff again.

Really, is this argument going to be brought up forever? So if we can't
make everyone 100% happy, we shouldn't do anything at all?

This isn't an argument anymore, it has become an idiotic circle jerk.
Stop it, I am getting tired of that!

> I doubt it's as simple as stated.

It is. We are already actively using it and you aren't even noticing. I
have sponsored at least half a dozen packages recently which were using
xz compression. No problems and no bugs reported at all with them.

If you like, I can verify them to work on my 1993 Amiga 1200, on my 1995
Sun Ultra 1, on my PowerMac G4 and my Raspberry Pi, just to make sure it
really works for everyone!

> And yes I do think there are some that would inject problems (such as
> killing init for a new startup that isn't compatible).

Dude, if you want to stick to 1985 technology, just use something else.
We don't have and don't want to be compatible to the original(R)
Unix(TM) because the original Unix is a piece of shit.

Have you ever sat in front of some ancient Sun, HP-UX or OSF/1
workstation using the original pure Unix design? It's so cumbersome and
uncomfortable to use, it makes you throw up. I had to deal with plenty
of these beasts in my career and I was always happy once I were back to
my Linux box. If you are using one of these, you can forget nearly
everything you ever learnt about Unix from Linux. It probably won't work.

If we are losing compatibility with old Unix stuff because we're
introducing new stuff to Linux and Debian, I can only say "god riddance!".

The "Unix Hater's Handbook" exists for a reason. I honestly think that
everyone who praises the good old Unix design has never actually used
any of the original Unices, they wouldn't praise them otherwise.

> There are all kinds of proposals continually that are unwise. And this
> one has been complained against and re-submitted often already.

Please provide viable sources, thank you.

> So why shouldn't I repeat past complaints others have made on previous
> posts.

I don't know, but I think you shouldn't. Progress will happen anyways.

> I think your singling me out.

My singling what?

</end of rant>

Cheers,

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/5192AC28...@physik.fu-berlin.de