[Openswan dev] First pass README update

[Harald Jenny]

On Fri, Oct 15, 2010 at 06:22:13AM -0400, Paul Wouters wrote:
> On Fri, 15 Oct 2010, Thomas Geulig wrote:
> 
> >>The real fix for those systems is to use posix compliant,  slightly larger
> >>versions of regex,sed,awk etc. Space gained from not having "id" or
> >>"dirname" is really meaningless.
> >
> >Busybox tries to be POSIX-compliant. "id" and "dirname" are available,
> 
> But often not compiled into busybox by people

As a example (although not relevant for this thread): On OpenWRT busybox is
compiled with dhcpd support as they do DHCP-serving with dnsmasq...

> 
> >and it's much easier to add these to an embedded system then Perl or
> >Python.
> 
> I understand. The verify/policy commands are more to help the user, not
> the experienced embedded engineer that gives feedback to its user via
> a webgui.

Hmmm on the other hand there may be a user of am embedded platform with shell
access who wants to debug his openswan too - or a developer who wants to give
the openswan developers a good feedback when he encounters problems?

> We will not introduce perl or python into the essential parts
> of openswan.

That's good to hear but isn't policy supposed to take over the role of eroute
for SARef (which isn't an unessential tool, at least for me).

> 
> >If there are problems using these commands, they should be fixed (in
> >Busybox).
> 
> They are mostly not broken, if compiled right. But again, often people
> leave out the "extended" support for some commands because it appears
> optional to them, such as awk/sed. Or simply versions that will never work,
> such as the ip command.

I think we got the point - so if we would be willing to use shell for these
commands we would need to ensure that the developers of embedded system get
correct instructions what needs to be configured/installed?

> 
> >Implementing Openswan commands in C would be another (good) option.
> 
> Yes, that is an option, but it takes time to do this.

But after reading this thread I am fairly sure that this would be the best
solution for this problem - do everything that can be done easily in shell and
implement the rest in C (as painfull as this may be).

> 
> Paul

Kind regards
Harald