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