Re: glibc_2.0.5c-0.1 uploaded to beezer
On Wed, 8 Oct 1997, Nikita Schmidt wrote:
> By the way, this version of glibc is vulnerable to the same problem as
> the Intel one: it has incompatible I/O functions virtual table. Please
> be aware.
That's what I thought. I wonder why they changed this after promising
that no interface changes would be made....hmmmm...
> I wonder what decision on this matter will be made in debian-devel.
> Speaking strictly, this is an interface change and hence new soname and
> new package name and all this mess.
Hmmm...I guess that's more debian-devel's matter than here, but if it's
not a major-impact thing, and since we are still in unstable status, then
I personally feel that it's not a big enough deal to change the package
name and soname. I'll have to read the glibc docs though to get a better
understanding as to what's been changed specifically, though, since my
brain seems to be absent today :P
> But, actually it may be easier to deal
> with considering that the change does not involve many packages and from
> the distribution point of view can just be merged with the libc5->libc6
> transition. In unstable it is not necessary to maintain backwards
> compatibility with unstable.
Do we have a relatively definitive list of packages that may be broken by
this? From what I can tell from the thread on debian-devel, it seems that
some of the packages written in C++ may be affected (at least those that
use non-standard classes).
If the amount of packages that are broken by this isn't that much, then we
can probably knock all of the necessary recompiling/repackaging out fairly
quickly (while making alot of the packages "official", btw, for master).
I'll go ahead and install the new glibc and see how it goes on my system.
Any tips, btw?
Chris
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: