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

Re: Delegation for trademark negotiatons with the DCCA



Anthony Towns writes...

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

> 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?
If acceptable, someone would need to do the work, but I think Jeff's work 
could be almost directly leveraged.

As to the people suggesting that we "steal the patches" that Progeny is using 
to implement the fixes (to their special packages, but are still relevant for 
unstable), yes. But the issue hasn't been about the patches, those have been 
obtainable from the other LSB implementors for a while now, Jeff just did the 
job of gather them all in one place and making them consumable for Debian 
(good work, we _should_ use it). The issue has been that Debian was unwilling 
to accept some of the patches because upstream had refused them. This has been 
an ongoing battle between various Debian maintainers, their upstreams, and the 
LSB project.

The LSB's charter is to document existing practice. If an interface change 
isn't acceptable to the maintainer of the canonical implemantion, then the LSB 
should drop it. We need to push back on these sorts of things. (It hasn't 
helped that other distros just accepted the patches and effectively forked, 
making Debian the only one willing to do the right thing)

Jeff,
Do you have a nice collection of patches used posted somewhere that we could 
review and either accept in the upstream package or push back and get removed 
from upstream/LSB?

Thanks,

-- 
Matt Taggart
taggart@debian.org




Reply to: