packaging was Re: Web Server Patch

[Joel Sherrill]

Till Straumann wrote:
> 
> How much more stuff will you bundle with RTEMS in the future?

Personally, if the code already exists as a standalone maintained
package, I absolutely 100% prefer that the RTEMS port be merged into
that package's standard source base.  They should include a 
README.RTEMS and possibly special Makefiles if it isn't 
buildable with the packages standard build scheme.  

This is how ntp, mdp, and all of the packages in Eric N's 
add-on packages are done.  Till's Cexp and NFS are handled
this way.  If necessary, the RTEMS CVS repository is available
for tracking modifications until the main source base accepts
the port.

On the other extreme is functionality custom built for RTEMS.
Some of that is (to me) should be clearly part of the main
distribution regardless of whether or not it is a separate .a.
This is stuff like APIs, some filesystems, OS system calls,
and core networking services.  

The middle ground is these packages like the GoAhead webserver 
which is  not known for resposiveness to bug fixes or for 
providing timely updates.  The PPPD is another one that is 
merged for a different reason.  My understanding is that the port
has a fair number of modifications.  I can see having different
web servers but I doubt there are lots of PPPD implementations 
out there.  So this category is up for debate on an item by item
basis.

Some functionality like XDR and RPC is (to me) core networking
infrastructure so I have trouble separating it into different
source packages.  

What we have tried to do is balance the complexity of putting
together an RTEMS application with the problems of symbol conflicts.
In general, each package shouldn't have anything pulled in unless
you reference its services.  And that is whether or not it is in
the same library.  So the main problem is ports of UNIX code that
provide duplicates of common routines and use common names for symbols.

So I guess I am really on the fence.  I tend to agree that the items
in c/src/libnetworking should be at least separately configurable
so they can be easily turned off if you intend to use your own.
But I don't like people having to build and assemble a lot of separate
items either.  It is error prone.

But the general trend is if it existed as a separate package before
it met RTEMS, it is best if it continues to exist that way and be built
separately.

--joel