What about the possability of moving forward with a mixed approach for the next major version?If there's a "dying need" for those applications, I wouldn't have a problem with that approach - but I don't really see the need for that at the time (as I said, the list of apps that won't compile against uClibc is growing shorter by the day). Besides, having to support a mix of glibcs sounds like a nightmare to me - not something a small group could handle, without some true glibc-wizard handling things.
The core system (and most packages) could be compiled against uClibc, while packages that require it are compiled against a newer glibc that would optionally be installed by those with enough room (ie: running from HDD/flash/CD-ROM/etc).
Or did you mean a mix of uClibc and glibc 2.0? To my knowledge, that part is already accomplished (since there are libcxxx.lrp packages for Bering uClibc). But to me, that's a "dirty hack" - it may work for most, but debugging those kinds of setups when things go wrong is a huge mess. Where do you start when somebody writes that "after I installed libcxx and package yy, service zz starts segfaulting"? - been there, done that (replace xx with whatever HP/UX 11 comes with, yy with Oracle 8 and zz with Apache 1.2) ;-)
Martin
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
