Fwd: busybox current status

[Bernhard Fischer]

On Thu, Nov 30, 2006 at 01:14:33PM +0100, walter harms wrote:
>
>
>Bernhard Fischer wrote:

>>> But if you don't use uclib it requires several libraries that busybox
>>> does not just to get login
>>> working.  Just getting to use the busybox lib for user/password would
>>> be a step in the right
>>> direction.
>> 
>> We'll provide the possibility to make busybox a PIE in favour of the
>> older approach that the initial "libbusybox" aimed at, so folks can just
>> link against
>> $ ls -ln libbusybox.so*
>> lrwxrwxrwx 1 100 100 15 Nov 30 10:05 libbusybox.so -> libbusybox.so.1
>> lrwxrwxrwx 1 100 100 17 Nov 30 10:05 libbusybox.so.1 -> libbusybox.so.1.2
>> lrwxrwxrwx 1 100 100 19 Nov 30 10:05 libbusybox.so.1.2 -> libbusybox.so.1.2.3
>> lrwxrwxrwx 1 100 100  7 Nov 30 10:05 libbusybox.so.1.2.3 -> busybox
>> 
>> and reuse our code.
>> 
>> Comments?
>
>LIBBUSYBOX is more or less a clever wrapper around the the libc. so far i understand
>was the approach doomed because the interface was to volatile to be useful in other
>project. In other words to make it useful we need a API freeze and a wrapper to
>the then current libbb. This can be done but would require a maintainer for that API
>stuff because the main target for busybox is not exactly to keep a stable API.

I, personally, wouldn't require a stable API. It's overkill. Or are
there volunteers? Even if there were, it'd impose complications and
maybe bloat upon busybox just for the sake of API compatibility, which
doesn't strike me as something we want.
If you have one program that want's to use functions from busybox to
make binary footprint smaller, then you can as well cope with eventual
small changes with it. If you don't think you can cope, Just don't do
it(tm). IMVHO of course.