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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]