[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Delegation for trademark negotiatons with the DCCA

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?:

> > 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.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: