Re: HEADS UP: I will be merging christos-time_t by the end of the week

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090105201701.GA445%panix.com@localhost>,
Thor Lancelot Simon  <tls%rek.tjls.com@localhost> wrote:
>
>The point is to allow programs linked only to the old libc to continue to
>work, without having to build and install two versions of libc.  I actually
>question whether that is worth the trouble.
>
>I think bumping the libc major also would be better, because then I think
>it might be feasible to modify the linker and loader to reject attempts
>to link a program to libc.so.90 when a dependent library wanted libc.so.80.

I think it is worth the trouble, this is why I went through the
pain of doing so. Even if you bumped the library you'd have to take
care of pwd.db spwd.db utmp, utmpx, wtmp, wtmpx (or declare a flag
day). I wanted people to be able to upgrade, and also downgrade.
I looked at the list of things to change in libc on a major version
bump (I even started doing some of them), and I thought that doing
all these changes *and* time_t, dev_t, and struct stat, rusage,
timeval, timespec ... just to name a few was a recipe for disaster.
So I decided to first to the time_t, dev_t, etc changes, and don't
bump.  Then wait for things to settle, and start working on the
things that need the bump. Then we can safely bump libc.

christos