Re: Linux Core Consortium

[Bruce Perens <bruce@perens.com>]

Steve Langasek wrote:

Changing library *names*, OTOH, is something quite different -- and in the
first case, providing "compatibility with the old names" totally defeats the
purpose of *having* sonames, whereas in the second case, it still sounds
like gratuitous change to me.
  

Steve,

I am not yet aware of the magnatude of the problem. Neither does Ian Murdock, we discussed it. We'd have to work with these guys a while to figure it out. It might end up being a non-issue, or a small number of packages.

Off the top of my head, if I had to provide two sonames from one library, I'd make a stub library that chained to the other name. No doubt we could cook up a shell command to produce these as necessary, perhaps as part of the debhelper package. We'd live with them for a while and then flush them, as we lived with a.out for quite a while without much pain.

being bound not just to an external *standard*, but to an external
*implementation* requires sacrificing autonomy in areas that have been
historically important to Debian, such as timely security fixes and
arch-specific fixes for architectures not covered by the LCC

Nothing says that we can not produce our own versions of libraries when necessary. I doubt that any distribution is really giving up that capability, and security fixes that are issued but still in the process of being merged into LCC should not invalidate one's certification. I would think that LCC folks might appreciate the help in fixing security bugs on a timely basis. Indeed, I am not so arrogant as to believe that we will always be the first to fix them. Maybe we can use their help.

It sounds to me as if we'd be the lead for multi-architecture stuff, nobody else does it to the extent that we do.

Can you provide pointers to concrete LCC proposals of library
renames, so that I can get comfortable with the technical specifics of
what's really at issue here?

They don't exist yet. If we work on this now, we get to make sure we'll be comfortable with them.

    Thanks

    Bruce

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature