SEUL: SEUL packaging, etc.

[Erik Walthinsen <omega@omegacs.net>]

> Ok, so what does this have to do with Debian then?
The decision to use RedHat was made before we were aware of certain 
initiatives.  The current plan is to base SEUL on Debian, hopefully aiding in 
the generation of a Debian-based Linux "core", which would be standardized, 
allowing packagers to compile their apps *once*, rather than 4 or 5 times for 
the existing distributions.  The core would be versioned as a whole, allowing 
for simple dependency checking against it, and no need to test a package 
against innumerable distribution/version combinations.  This has the effect 
of much reducing possible vendor excuses, as well.

> Neat.  I hope you get it working, but until then we do have a working
> package system here on debian-user.  We call it dpkg.
Precisely.  I believe what he was mentioning was some kind of front end.  I 
have not looked at Diety, but I believe that may be much of the solution.  
Note that, however, Diety is designed for today's typical "Linux User", which 
is not the target audience for SEUL.  Because of that, even Diety may be 
overkill.  I would like to make it almost trivial for a user to install a 
package, i.e. click in a hypertext help/wizard window and it will install 
what is required for functionality set "X" (e.g. "I want to set up a dialup 
account with email masquerading and a DynDNS hostname", ok, that's maybe a 
little complex...).

> Hmm, well, you must not read the Debian lists then :)  There's been a
> lot of sniping recently about 1.3.1 (bo) _NOT_ being kept up to date.
> Most users seem to prefer "up to date" whether they need it or not.
That may be true of the current "Linux User", as defined above, but not of 
the end-user that SEUL is targeting.  A unified core will help much in 
these goals, though.

> does nothing to further the goal of this list: Helping Debian Users.
I agree.  This discussion should be moved to seul-project and/or the 
appropriate Debian developers list.

> I'm not saying your project is unimportant.  I am saying that its
> discussion doesn't belong here.
Quite right.

> No comment :)
The use of sendmail may also be up for debate.  At the time sendmail was 
"decided upon", we had intentionally restricted our choices to sendmail and 
qmail.  The debate was over two things: capabilities and license.  sendmail 
came out on top in both of those categories.

This does not mean that sendmail is necessarily our choice.  I intend to ask 
people to write up their experiences with any and all MTA's they have seen, 
used, or just heard of (and then tried, of course).  These documents will be 
formalized and posted to our site, and will then form the basis for a 
point-by-point discussion to decide which MTA is best.  Once a general 
consensus is reached within the team responsible for this decision, we will 
have officially decided on one or another.

There are more procedures we have yet to put into effect, partially because 
of lack of underlying services (our web site is still being pieced together, 
for instance).


I hope this help clear up some questions about SEUL.  If you have more, 
please feel free to email seul@seul.org (a two-person alias) and we will do 
our best to answer them.

TTYL,
    Omega

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user