Re: Comparison and rebuttal of Raul Miller/20040119-13 against Andrew Suffield/GR Editorial
At Mon, 26 Jan 2004 15:12:54 +1000,
Anthony Towns wrote:
> On Mon, Jan 26, 2004 at 02:17:16AM +0000, Andrew Suffield wrote:
> > On Sun, Jan 25, 2004 at 11:51:13AM +1000, Anthony Towns wrote:
> > > On Sat, Jan 24, 2004 at 12:02:06PM +0000, Andrew Suffield wrote:
> > > > On Sat, Jan 24, 2004 at 02:28:13AM -0500, Raul Miller wrote:
> > > > > You seem to be asserting that we, as a project, shouldn't recognize such
> > > > > standards violations as bugs.
> > > > Correct. Violating the LSB is not a bug.
> > > I'm sorry, but you're wrong. It's not simply a bug, it's a release
> > > critical bug. The responsibility of finding a fix belongs to the -lsb
> > > group, but the maintainer is still required to apply the fix in the
> > > usual timely manner expected for RC bugs.
> > That's like saying that violating POSIX (when POSIXLY_CORRECT is *not*
> > set) is a release-critical bug in glibc.
>
> No, it's not.
>
> ] (p) Linux Standard Base
> ]
> ] Packages must not conflict with requirements of the LSB,
> ] v1.3. (eg, if you provide a library specified in the LSB, you
> ] must be compatible with the LSB specification of that library)
> ]
> ] Basically, you should be LSB compatible. You can expect a bug
> ] report to be filed if you're not, and if you don't know how to
> ] fix the problem, you should email debian-lsb@lists.debian.org
> ] for assistance.
>
> -- http://people.debian.org/~ajt/sarge_rc_policy.txt
>
> The only RC requirements we have for POSIX conformance are indirectly
> through requirements for LSB/FHS conformance, or because that's what
> maintainers expect of their own packages.
Indeed.
Conforming to POSIX _perfectly_ is hard any time for various OSes and
systems. For example look at the recent NPTL updates. NPTL fixes
various pthread concerns, but it needs a long history (from 1997 or
so) to modify both kernel and glibc.
Moreover, if you read specs deeply, then you may find even
specification error. And there are a lot of "shall" "may" words, and
in that case we don't need to conform to such item if we have reasons.
Be careful that exactly matching to the specification blindly misleads
the meaning or the purpose of specifications and standards.
Regards,
-- gotom
Reply to: