Re: SEUL: Common SEUL/e-linux tools needed

[lso8219@cs.rit.edu (Loren S Osborn)]

> 1. To my best understanding since SEUL and E-Linux work on different GUI
> platforms, Messeges crossposted in both groups should be concerned only in
> the core logic of installation and not in the gui part.

Not really... they (*currently*) both use the the X Windowing environment...
one will be based on the KDE desktop/window manager, and one is undecided.
Tcl/TK will work *DIRECTLY* on X, so *IT* will work on both systems... it would
probably (in *BOTH* cases) be a good idea for them to make Tcl/TK tools look
more native, butt that's a pickey look&feel issue... Tcl/Tk code can (and
should) be shared... although it probably won't end up in the final release...

I hope that in a few years, both distributions will have switched to Berlin...
but that  isn't around yet...

> 2. As far as I see itw package management tools are for suphisticated users.
> The simple distribution should work ona tool like the windoze InstallShield
> that will interprate installation scripts, and provide the defaults where
> needed.

No... package management tools allow you to add new software... I agree that
SEUL's version shouldn't provide as many options (or at least should *HIGHLY*
reccommend defaults...) on the configuration, but how do you want to do w/o
package management in a system...

> 3. For this purpose I think the following core logic parts should be
> implemented for the new distributions:
> 
> - Hardware diagnozing routines to autodetect hardware.

Most definitely... (I forget this one)

> - Search for installed libraries and versions.

A package manager will remove the necessity for "searching"... it will know...
We should readily provide an "update" feature, in case the user...
(intentionally or not) mucks around with the system and adds/removes
packages...

> - installation script interpreter

this is last priority (not least important)... we should get a working system,
and then break it into pieces, then assemble a installation script...
(personnally I think it would be neat if the first thing that the user sees
is a penguin waddeling across the screen :)

> I see the installation scripts as composed of
> - pre install tasks
> - actual installation steps - each installation step is designated a name,
> and associated with actual file copying,authentication , and GUI components
> File or section in script
>  - post install tasks

I think this should be saved for a little bit, until we have a working, or
semi-working system...

> Of course from my proposal, existing RPM and DEB will not install with this
> format, but if we make a good developer tool for generating these packages
> it will be easy for either one of the people involved with the specific
> distribution or the developer to generate the package.

This was my intent, although it would take many man-hours to convert sunsite
to SEUL Package Format...

> 4. There has been talk about a Partition Magic clone. Though very nifty to
> the advanced user since partitioning is a one time task for the simple user
> I believe there is no need for such a tool.

On the contrary... although this is an advanced tool, it would make simpler,
and less intimidating the setting up of multiple partitions or OS's on the
same system... 

> 5. I believe we should designate a few generic platforms to work on and
> start from there.

Yeh, but as long as we have the source-code, we could always re-compile...
(BTW, since SimOS has MIPS support, maybe we should add that to our list??? ;)

Comments? Suggestions?

Loren