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.
> I'd bet that you'll go back on those words eventually.
> Bugs are things that break software, not arbitrary third-party
> specifications.
*shrug* It requires care to manage, but that doesn't make it impossible.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we could.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Attachment:
signature.asc
Description: Digital signature