Steve Langasek wrote:|
Steve,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.
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.
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.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
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.
They don't exist yet. If we work on this now, we get to make sure we'll be comfortable with them.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?
Description: S/MIME Cryptographic Signature