Re: Core and Layers

[George Bonser <grep@oriole.sbay.org>]

On Wed, 21 Jan 1998, Erik Walthinsen wrote:

> Yes.  This idea is still being refined in my poor, overloaded little brain, 
> but here's the idea as it stands:
> 
> The Core would be the basics for a system to run, do some basic useful 
> things.  This would include most of the things that are currently in RedHat 
> or Debian's "Base" groups.
> 
> Functional Layers could be added, for instance, a mail layer, an X layer, a 
> configuration layer, a development layer, etc., ad nauseum.  We'll have to 
> decide how much of this we need to do now for SEUL, and how much can be 
> done later for use in other distribs, but now I'm diverging... (hey, it's 
> 1:30 and I'm supposed to be asleep)

I think the core specification (core really being a spec more than
anything else, I suppose) gives the developer and distributor a level of
comfort in knowing that a 1.0 compliant app will run in a 1.0 compliant
distribution.  Users knowing that they have a 1.0 distribution will know
that they need to look for 1.0 compliant apps and will know that they will
run.

Example:  1.0 might consist of a certain version of the kernel (say
2.0.29-2.0.33) a certain version of libc, gcc, perl, bash, csh, ld.so,
etc. so that a program compiled and run on that system is likely to work
as expected.  This allows a commercial software vendor to put on the box
"Requires SEUL 1.0 Compliant Linux". As for filesystem layout, package
formats, and config file location, that is a completely different spec.

This raises an intersting idea that you touch on below...

> I'll mention this while I'm thinking of it: a Layer is an abstraction 
that 
> provides capabilities X, Y, and Z.  Any number of implementations of a 
> given Layer might exist, and dependencies might be done between Layers.  
> For instance, there might be a bare-bones mail setup that's just enough to 
> deal with root's mail, for use in a system where all the users have MUA's 
> with built-in pop/imap (i.e. Netscrape).  This entire Layer could be 
> replaced by a complete, highly configurable, server-scale sendmail/smail 
> implementation that provides all the services of the bare-bones version, 
> and more.

The layer specification could be added to the basic spec as a dash number
or letter.  For example ... A system using the dpkg package manager and
our filesystem layout might be a -A system. A system that is A compliant
and is also running a mail transport system locally might be a -B system.
A -C system might be A and B and a web server of some sort. A -D system
might be a -C with ssl support.

In this way, software might say "Requires a 1.0-C compliant system".  The
user then knows exactly what they need to have in order to run that
system.

> 
> Dependencies could get interesting, such as how do you tell the system that 
> package or Layer X requires capability Y from Layer Z, when only Layer 
> implementations B and C provide capability Y?  I'm sure there are ways to 
> deal with that, using a combination of Layer and virtual-package deps.

One way around this is to require layers to be cumulative.  A -D system
has everything a -C system has plus some additional capability. Actually
Debian has a way of doing this in its Provides: mechanism.  If a program
requires News Transport System, it looks to see if it has a package
installed and configured that provides News Transport System. It does not
matter if you have cnews, inn, or leafnode ... as long as you have a news
spool and a way to move articles.

George Bonser 
If NT is the answer, you didn't understand the question. (NOTE: Stolen sig)
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.