Re: Bug#186140: Bug#206210: diff: does not comply with LSB 1.3 (fwd)
Michael Stone wrote:
At least we agree on that. :)
We also agree that the feature should be included upstream. :)
Yes, which means a *comprehensive* examination of the basic utilities.
The test suite isn't that. It also needs to be done on a
package-by-package basis. (I'm not impressed with the idea of a
coreutils package with a list of utf8-enabled features and a list of
features where utf8 is broken--which is, I think, where the patch in
186140 will leave things.)
I have not claimed that the patch will add proper UTF-8 support to
coreutils, but it looks like it does not break single-byte characters.
All it does is make the LSB test suite happy so we have a chance to get
an LSB certification. Unlike Red Hat, we should not claim full UTF-8
support.
Then why haven't they been merged upstream if they're so well tested
correct?
I don't know. But the reasons why diff's upstream authors have not yet
accepted a similar patch are (from #184886):
| Thanks for the bug report, but I can't accept that patch, for two
| reasons. First, we'll need copyright papers signed to accept large
| patches like that, signed by the author of the patch.
| Second, it's too complicated. There should be just a single set of
| code to maintain, not two separate copies of the logic, one for
| unibyte and the other for multibyte. The single set of code might
| need to be compiled twice, for efficiency; but we shouldn't have to
| maintain it twice.
Maybe the situation is similar for coreutils? The question is now if we
want to wait for a better patch or if we can life with a patch that is
not optimal but helps us achive a goal (if LSB certification is a goal).
A start is something you do at the beginning of the release cycle, not
the end.
I really like the fact that you don't blindly accept patches to your
packages, especially since it's an essential package. And I can
understand that you don't want to fork from upstream but why don't to
build test packages with this patch applied like you did for ACL
support? We could then see if this patch can still by applied (IIRC is
was for a different upstream version), if the package is not obviously
broken and if the LSB test suite runs without failures. So we at least
know how far away we are from LSB certification.
Stefan
Reply to: