Hi Matt,
So what would Debian's opinion be on using the possible suggested work
around? It definitely might help us all focus on one set of problems
(LSB3), and come up with solutions that would benefit all the distros
built ontop or around Debian Sarge. Sarge is going to be around probably
for the next 18 months as stable, so moving forward with LSB 3.0 would
cover that time period till Etch is released.
Thanks
Dave
Mats Wichmann wrote:
On Mon, 2005-06-27 at 10:29 -0500, Ian Murdock wrote:
Matt Taggart wrote:
Also is Debian interested in skipping LSB 2.0 compliance and moving
straight to LSB 3.0?
I don't think so because sarge can't be 3.0 compliant (glibc isn't new enough
among other things) so I think 2.0 for sarge and 3.0+ for etch.
Have you seen this?
http://www.licquia.org/archives/2005/06/16/a-new-approach-to-the-lsb/
http://www.licquia.org/archives/2005/06/16/a-new-approach-to-the-lsb-part-2/
In other words, we're working on a way to make sarge LSB 3.0 compliant
without having to introduce an updated libc (and break compatibility).
Hey, that's what the "special linker name" is there for. Someone argued
very convincingly for it a long ways back, and a few distros even used
to provide a parallel glibc with it, but it's not been used much
recently and we've actually had to fight off some criticism to keeping
it around.
By the way, if people think we should be more conservative in glibc
"advancement", it would be good to let the LSB project know that. There
hasn't been a lot of negative input on the LSB2 and LSB3 requirements in
that area, and some fairly vocal pleas to move forward because of what
was claimed to be crucial support on certain architectures.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
