On Sat, Nov 07, 2009 at 04:04:00PM -0600, Rob Landley wrote: > Since you asked, my thoughts are "oh please no". Let's not open this can of > worms. Busybox is not a C library, it's not a kernel, and those are NOT OUR > JOB.
I agree that we shouldn't be reimplementing gnulib, but on the other hand busybox is expected to run on a variety of systems. I don't think it should be an issue supplying replacement functions for the handful of nonportable functions that have been identified. > This strikes me as a case where busybox not only can say no, but _needs_ to. > If the project want to avoid using extensions, and eliminate existing uses of > them, that's a defensible position. If the project wants to document our > requirements (SUSv4 plus X and Y and Z extensions), that's' fine too. But > reinventing the C library and making this project's problem to maintain? > Erik > kept uClibc a separate project for a _reason_, and we _do_ work with that... I think it's a good idea that Busybox documents the requirements that it expects, but I don't think eliminating some of the useful APIs it's using is necessarily a step forward. >>> Dan -- http://www.MoveAnnouncer.com The web change of address service Let webmasters know that your web site has moved _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
