Things this group creates:

AS : Automated Systems

design/impl of sane automated systems for things like log rotations, periodic security checks(?), etc. these should also have appropriate front ends for communicating with the correct user/sysadmin, and for reconfiguration.

CAs : Control/Config Applets (system)

control-panel (or ctlpnl-like) app[let]s for non-aesthetic system tweaking, like telling the system about hardware changes, software installs/deinstalls, configuring time, etc, etc... (strictly aesthetic things (CAa) are done by dev-ui!)

CFstd

config file std/spec/editor thingy. [ you know what it is ; define it here when i have time... ]

FM

File Magic, taken one or two, or ten steps further... filetype-recognition/auto-open support (note this will be called by hooks from ui-written file mgr, and other places).

REG (istry)

menu item updates? relation thru installed-software "registry"... this task is shared with dev-ui. fun.

software install/deinstall: (SID)

base pkg system will reuse existant pkg mgrs, but add something more expansive than a current package manager -

• GPKG (generic) it will ideally be a unified interface to deal with multiple package formats and make some attempt to arbitrate if the user installs something bizarre/conflicting-among-standards -- hopefully things will just end up becoming more standardized as linux matures, in the long run, and that problem will crawl away in the shadow of a unified packaging standard. o the interface will also encompass things like tar and install, perhaps recognizing some special (optional) "seul control file" inside them (eg hints for registering programs in the control panel/on the desktop or taskbar).
• BPKG (big) deal with a more macroscopic view of installation, like installing a bunch of pkgs that depend on each other as one unit, transparent to the user (i call this a "package set").

note: GPKG and REG might involve 2 things:

1. Hacking the package database for whatever manager is being used. (to read foreign formats (GPKG) and log seul-invented info (REG))
2. augmenting it with a secondary database.

Impl notes:

GPKG:

• should initially involve just providing pkg conversion tools for compatibility (eg alien); focusing on robustness analysis and documentation to make further development easy. think about grouping/doc'ing such that joe random can find them in the menus and learn how to use them quickly. (note that later, these will also be auto-launched once we start detecting filetypes and having the filemgr do that, so make sure a robust set of them is on the system!!)
• could later involve taking whatever is becoming single dominant pkg mgr (i hope there will be one), and adding compatibility features for it to recognize foreign files intelligently. or writing a wrapper that calls the right tool for the right job. debate which approach is better later on...

REG:

• may require pkg mgr hack to read "seul hints" built into pkgs. preferably will not need that at least when reading sane package files, since we can prob do something with the [pre,post]-[un]install scripts to make reg updates happen right; and things that are not sane pkgs (tarballs, ...) we'll have written our own wrapper for anyway, so we have easy code control there.
• where/how to put registry stuff? :)
  note: gnome and debian methods should be watched/studied carefully; they appear to be doing this.
  note: see how this relates to ui as well as system? hence must be shared design between admin and ui.
• dev-admin task: picking up the hooks left by dev-ui in the file mgr, interfacing them to the registry.

What?

Suggested development plan:

1. research packagers, db's, other pertinent material...
2. propose/defend spec for seul db interface.
3. generic pkg interface thingy. make some lists of existing software and level of maturity. design/hack/write some code/script for enabling semi-generic packagement/otherwise enhancing pkg mgt. have sensible debugging output (for development purposes)!
4. start on "control panel" apps -- specifically config file editor,
5. continue design of generic pkg interface.
6. polish admin apps. follow what should be a mature gui spec by this time.
7. ( note: "ctl pnl framework" app. moved to dev-ui.) dev-admin does the guts of ctl panel sys interface which ui will leave hooks for, but only once ui system done!! this needs to be serially developed. (not bad, since admin is stalled at the moment anyway.)

Note to crusties: BIG diff from ooold plan: pkg mgt and config mgt are now separate burdens. combining them (the original seuldb "registry" concept would have sucked due to problems with implementation of this "total control" big-brother type system... if you care, you probably know the rest of this story so i won't waste my breath.

How?

This group is currently without an official leader. Anyone wishing to help in the group should email the sysarchs (i.e. SEUL project leaders) on seul@seul.org.

Who?