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

Re: Bug#373704: sort -k does not count fields the same as gnu sort



On Saturday 13 January 2007 22:10, Steve Langasek wrote:
> "Potentially leading to random breakage" doesn't really justify a
> critical severity when there are a limited number of packages making
> use of busybox (and busybox sort in particular).  Does this bug
> actually break d-i, and if so how?

Let me start with a little quote:
<ifvoid> fjp: why is it rc?
<fjp> ifvoid: Basically because it can cause unexpected breakage in 
anything that uses busybox sort.
<fjp> ifvoid: My feeling is that the behavior now is even worse than the 
original bug.
<fjp> ifvoid: Not sure if RMs would agree though.
<aj> unexpected breakage in busybox sort sounds horrible
* Maulkin nods

"Critical" is possibly too high if you just consider Debian packages. 
However, if you also consider use of busybox in embedded devices where 
scripts written for GNU sort are being run (which apparently is a big 
market for Debian), it could still be justified.
It can at least potentially break unrelated software.

I think "not suitable for release" is quite justified in this case, 
especially as the sort function in Sarge works better. The original fix 
for this bug has caused sorting with a delimiter (-t option) to work 
worse than it did.
In the past, it was "off by one field" in an edge case (lines starting 
with delimiter). Now sorting with a delimiter is completely broken for 
anything but the first 2 fields.

For D-I this currently only breaks a minor backwards compatibility 
function (correctly merging finish-install.d and prebaseconfig.d hook 
scripts). As this has basically been broken since the start and as far as 
we know there are no _official_ udebs using it anymore, this is no big 
deal.


I've taken a look at Goswin's analysis and patch, and it looks clean to 
me. I've also done a lot of testing with the patched version, and been 
discovering a lot of things about sort in the process (as well as a real 
bug in GNU sort: #406785).

I've adjusted and extended the test suite (new test script attached), as 
some of the tests were based on a misunderstanding of how sort is 
supposed to work (see also #367891).
All tests now give the correct results and are the same as when using GNU 
sort (except for the subrange sort which is broken in GNU sort).

With current busybox sort, three of the tests in my revised set fail:
FAIL: sort key field subrange with reverse option
(This is actually the same error as in GNU sort, so current busybox is 
consistent with GNU in that respect...)
FAIL: sort key edge case with -t
FAIL: sort key with (leading) delimiter

I have also seen a few cases where busybox sort now behaves different from 
GNU sort, but those all involved keys over multiple fields with numerical 
sort option. See #367891 why this is not really supported anyway. The old 
busybox sort also had some differences in these tests.

I'll try to do some additional testing on this, and I would like to 
discuss one point with Goswin.

Cheers,
FJP

P.S. I fully agree that this is not the best time in a release cycle to 
dive into such things :-/

Attachment: sort.tests
Description: application/shellscript

Attachment: pgpPaFU178YGj.pgp
Description: PGP signature


Reply to: