Separate packages (was Re: Web Server Patch)

[Ralf Corsepius]

Am Fre, 2003-04-11 um 02.17 schrieb Chris Johns: 
> Ralf Corsepius wrote:
> > Am Fre, 2003-04-11 um 00.26 schrieb Joel Sherrill:
> > 
> >>Till Straumann wrote:
> >>>Please consider making each of these applications a separate
> >>>library, at least.
> > 
> > Why? Where are the benefits? I don't see any.
> > 
> 
> A couple of questions come to mind. Please excuse answering with questions.

I did the same ;) ...

> Should we add more packages ?
IMO, the answer depends on what you are referring to.

I'd like to categorize these into
a) Extensions to the "RTEMS core" (eg. pthreads/posix, itron) 
b) Extensions to the "RTEMS kernel" (eg. drivers)
c) Integrated applications (telnetd, web-server)
d) Add-on applications/libs (ncurses, libiberty, etc.)

All these things are technically possible, and there are many options to
handle these cases.

However this categorization is pretty weak and leave a lot of room for
interpretation. Which libs and apps are integral parts of the "RTEMS",
which are integrated but optional, and which are real external add-ons?

IMO, all this boils down to 2 essential issues: packaging and
application run-time/compile-time configuration.

I don't think RTEMS has satisfactory general solutions for both issues,
instead we have a "pragmatical pursuit to functionality", resulting to
the current status quo.

> For example I have Net SNMP (see the contrib dir) and Python (not full ported) 
> running on RTEMS. These are large packages that are constantly being worked on.
> 
> If not then what should go in (why?, and who decides?) ?
Well, you know, ... RTEMS is governed by a dictator/benevolent tyrant
(Joel) ... and a gang of collaborators (The SC) ;)

> Some reasons to keep packages separate are:
> 
> 1) Scalability.
>   a) Putting everything into a single lib slows linking down.
Hmm, really? Not very significantly, AFAIS.

>   b) The more packages you merge together the more revs you need to make.
Not really, IMO.

If keeping packages outside of RTEMS, you probably are just not noticing
potential problems in many cases. You are "just believing you are doing
the right thing(tm)" but actually are messing up things (remember the
libnetworking/kern_sym.c, strlcpy issue - Probably nobody would have
noticed the problem, except for some "ill-minded bug reports to pop up
twice a year" )

>   c) Testing time takes longer for Joel who releases the RTEMS package.
This is his job - (And his Dual-XX-GHz-Xeon probably is fast enough ;)

>   d) Increased complexity to build it all. RTEMS would need to become
>      a superset of all package build options and configuration. We currently
>      have a range of configure options, header file defines, and runtime
>      options.
This is not true - We could have a RTEMS "uberbaum" similar to the one
applied by the Cygnus/GNU uberbaum - You can get everything at one, you
can only get parts of it. ...  The actual problems are elsewhere (Eg.
many internal details to be solved)

> 2) Package Support.
>   a) We should try and keep RTEMS support for a package in the package.
>   b) A stable build environment in a package will easy package upgrades.
>   c) Separate release cycles for each package.

Yes, but ... what prevents you from already doing this? 

> On the negative side building an application requires a large stream of lib options.
Well, for external packages, using them with RTEMS should not be any
different from using them under other OSes.

However, there are cases, we can't do much about, because of issues
external of RTEMS or its toolchain (Eg. packages such python which do
not support cross-compilation). These packages either need to be fixed
(in most cases a very tedious effort) or to be hacked.

> Getting package configure scripts to work can be a bigger job than the porting of a 
> package.
Yes, but ..

... integrating packages obeying Cygnus/GNU configuration conventions as
drop in packages into the source-tree is close to trivial, or at least
do-able with little effort. This basically applies to most packages
using autoconf/automake.

Keeping such packages completely outside of the source tree is the
status quo. Configuring them is the same procedure as on any other OS,
except for many packages not supporting cross compilation, and RTEMS not
providing much help to ease such tasks.

>  Net-SNMP and Python and good examples of this point.
Yes, but ... 

... having had a glimpse into these packages' configurations, these
packages seem to be worst case scenarios to me ;)

Ralf