[BusyBox] Improving Our Development Process

[Vladimir N. Oleynik]

Mark Whitley wrote:

> Okay, gang, the time has come for an explanation about the whole
> netkit-tiny seperation plan:
 
> There were a few reasons offered originally, like being able to suid
> netkit-tiny while not having to do the same for busybox, 

It is not a problem. My decision with suid-wrapper in 300 bytes I
resulted - completely the working decision. Netkit-tiny also it is
impossible to make all suids, and entering of dump of privileges there
where them is primary should not - litters a code and raises risk.

> makes the very good point that we could simply build two executables
> from the same codebase. Alex (and others before him) futher make a
> good point that splitting up the apps would cause some redundancy in
> shared code (i.e. utility.c) which
> could lead to further maintenance burdens (somebody fixes a bug in
> busybox utility.c, but doesn't fix it in netkit-tiny utility.c, etc.).

And it is a serious problem. The result is already seen, uclibc has
emulation libnss_files, but busybox and tinylogin have own, besides
not compatible. It takes away a lot of time from me - each time at an
release to forward this code (it you see not only in utilites.c).    

> One could also argue that the applets should be kept together so
> people using it can decide for themselves what they want to compile
> into however many executables they want.

I do not think, that for people a serious problem will make 
from busybox so much executables, how many it will be necessary. 
Sharing on some programs brings to nothing usefulness 
STANDALONE_SH, let alone implementation shell :)

> In short, there is no technical reason why networking apps *can't*
> stay in busybox, and in fact there are some pretty good reasons for
> keeping all the applets in one codebase. I went and asked Erik about
> this (seeing as how he sits right next to me and isn't on the road
> this week), and he said that the biggest reason for splitting up
> busybox is to make life a little easier on him, cuz maintaining
> busybox is a big job, one that consumes a lot of his time (and he
> already has a full-time job).

Hmm..
What turns out in the total? Because of problems with uclibc you
do not want to include e2fsprogs, therefore busybox can not be applied
as an rescue disk. Because of your strange idea of exception
netkit, busybox can not be for the router. 
And? Games study distribution?

> So, we sat and brainstormed and came up with several solutions, 
> which we believe will be good, long-term ways of improving our
> development process.

[many many skip - has eaten the mouse]

On compilation of these long requirements you find time :))


[ Joke. You do not love cats? Yes you to prepare for them for meal do
 not know how. ]


--w
vodz