On Wed, Sep 28, 2005 at 03:21:45PM -0700, Matt Taggart wrote: > > Note that the reason it's not official is that the folks who're working on > > LSB support have declined to respond to repeated requests from the RM team > > about what that involves [0].
> Yeah we suck. BTW - Why wasn't this sub-thread cc'd to debian-lsb? It is now. > I propose that our etch goal be LSB 3.x. There are still some issues to fix > but we're as close to implementing 3.0 as we are any other version. There's a > 3.1 in plan for later this year, it mostly bug fixes and other stuff that > shouldn't affect our compliance so we should be able to target it. Did you happen to see the comments about getting a sane option for init script handling into the LSB, so that we don't get stuck having to argue with LANANA at some later date?: http://lists.debian.org/debian-project/2005/09/msg00224.html > > I think it's pretty telling that in spite of their PR position on staying > > 100% Debian and contributing all enhancements to Debian, that Progeny's > > working on making their product support LSB 3.0, while leaving Debian > > to stick with LSB 1.3 due to lack of interest. > The DCC LSB 3.0 compliance is being implemented using the "LSB linker > hack"(tm). Since the LSB uses it's own linker, it is possible to deliver a > custom ld-lsb.so.# that uses compliant system libs where possible and then > redirects certain things to alternative libs where the system lib isn't > compliant. > It's not clear if such an approach would be appropriate for a sarge point > release. I *think* it would be OK as it doesn't change any existing system > ABI. About the only objection I can think of is that it would require > changing > the lsb package in order to add in the new linker hack. That would change > existing behavior, but since it's changing it to fix compliance I think that > could be considered a critical bug fix worthy for a stable update. What do > you > think? Er, surely it's a much larger change than just adding the new linker hack -- it also requires adding in forked copies of several libraries. It's ultimately Joey's call, but I think it would be far preferable to try to fix these lapses in the core libs instead of shipping two copies of libc and libpam with sarge r1. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature