SEUL packaging, etc.
> 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
> 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.
> 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,
I hope this help clear up some questions about SEUL. If you have more,
please feel free to email firstname.lastname@example.org (a two-person alias) and we will do
our best to answer them.
Erik Walthinsen <email@example.com> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .