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:
pgpc7n2EUWJ6K.pgp
Description: PGP signature