A question of philosophy

[Denys Vlasenko]

On Thursday 03 February 2011 11:45, David Collier wrote:
> Denys,
> 
> your suggestion above for fixing tar to work with stdin is wonderful -
> and I'm sure it will work.
> 
> But it illustrates the different world-views that you and I have. In an
> illuminating way.
> 
> You think/speak as if busybox is infinitely mutable, and an issue can be
> changed by improving it.

Of course, that's what developers do: they change software.

However, I do not change busybox in a random way. I generally try to make
busybox tools more similar to tools available on "big Linux",
so that people can use the same scripts and expect the same
behavior.

In this particular example, "tar -T -" is supported by GNU tar,
therefore I made busbox tar to do the same.


> I think of the busybox version I find on 
> existing computers as part of the fixed background, and am looking at
> ways to work with any/all of them without changing them.
> 
> If I need to do something to my application, I would like it to work on
> 
>     the systems I have in the field running feature-lite busybox 0.60 
>         ( Good Lord )
>     the ATNGW-clones which run 1.13 non-desktop
>     the dev sys on my desk running 1.17 desktop
>     the PCEngines board which has Debian, 
>         but for some reason also has busybox 1.10 lying around.
> 
> I have now understood that 
> O different revisions of busybox have made different choices 
>     - the standard columns output by ps have changed over time.
> O even the same issue level of busybox may have been built with
>    or without many options - so the ps command may, or may not,
>    support the -o option to customise it's output. 
> Therefore I can't depend on the field order, nor on the presence of an
> option to alter it
> I've solved that by poking around in /proc ... but heaven help us, that
> may not even exist on some computers, so I will need yet another level of
> complexity for full portability :-(

Well, world is full of computer systems, and their upgrade cycles
can be wildly different (and sometimes really haphazard).


> Without risking breaking those boxes, which are sitting in fields in Peru
> and other places, and I CANNOT afford to go and reboot them.
>
> Now you might WELL say to me that I'm looking at it wrong. You may say
> that when I install my updated s/w I should also install a new busybox
> exe, on whatever machine, and use it.

No, I understand you might have no control over that.


> You might even say that all of my s/w should use "busybox ps", or set a
> path at start-up so that busybox is preferred to any Debian utilities
> lying around.
> 
> Maybe that is the right approach, and I should get used to the idea that
> busybox is actually part of my app, not part of the system. Except there
> are things in /etc/init.d that use busybox too. Maybe I need to download
> and update EVERY script on the system with my app. Better find them all
> first.
> And if anything else I don't update is doing system() calls I'd better
> pray the new busybox works the same.
> 
> Perhaps I should set up myapp/sbin myapp/bin myapp/usr/bin and
> myapp/usr/sbin and stick those on the front of the path, and set links so
> my app sees my latest busybox, but any existing s/w on the machine sees
> the environment it was used to...
> 
> Do you, or does anyone else here, know how to square this circle?

You will need to test your scripts on every deployed config
and try to write scripts so that they work on all configs
you support. If this is impossible, sometimes you will need
to have several version of a script.

To reduce amount of PITA, try to minimize the number
of deployed configurations.

-- 
vda