> ...the FAQ ToDo list reads:
>
> libc e h 9 convert to glibc6
^ ^ ^
| | + - Priority, 1=highest 9=lowest
| |
| + - Effort: High (h), Medium (m), or Low (l)
|
+ - Type: Enhancement (e) or Bugfix (b)
So, the line in the FAQ says that this task is an enhancement, not a bug
to be fixed (thus less urgent than all 'b' entries), requires the most
effort, and is the lowest possible priority. So, yes, converting to
libc6 is on the list. Given that the list of things above it on the list
is getting longer, not shorter, it is reasonable to characterize it as "I
am not intending to convert it to libc6". However, I would be more than
happy to have someone do this, and I'll be glad to distribute the result.
It does, of course, require recompiling EVERY program...
Priority is "bang" and effort is "buck", so I look for "x l 1" which are
the things with the most "bang for the buck", meaning it is really
important to be fixed and can be done easily. Of course, bugfixes get a
push up, probably it has the effect of adding 3 or 4 to the priority. The
libc6 conversion is harder than ANYTHING else on the list, because
everything is tweaked during building by hand to make the object file
smaller, and EVERYTHING will get bigger. That is, of course, *after* I
manage to get libc6 under 416,361 bytes, the size of the libc5
library... That is the 'buck'. As far as 'bang', there are really not
many reasons to do it, that is, _how_ is libc6 better on a rescue tool? I
have few specific examples. The only _very_ clear reason is that it is a
pain for libc6 users to build libc5 executables for tomsrtbt. That, I do
have a fix for, I will be distributing a foolproof libc5 compilation
thing.
Now, I am optimistic that it is doable and worthwhile. Or maybe I'll try
the Cygnus 'newlib' or write my own libc and call it tomslibc, which might
actually be easier than fitting a current libc6 on tomsrtbt...
-Tom
