dpkg not part of core?

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

I think now I understand what omega ment at the end of our IRC meeting and
this is a short note to clarfy something.  Dpkg is four different things.
First, it is the description of how packages are maintained.  This
includes the databases of available and installed packages and the
database of current status of these packages along with their dependancy
and conflict information.  Secondly, it is a set of low level utilities
that allow higher level programs to access these databases and perform
functions such as dependancy checking, package queries and installation.
Thirdly, it is the dpkg executeable command that allows manual
manipulation of packages and overriding of dependancies and conflicts.
Fourthly, it is a set of higher-level interfaces to the lower level
package manipulation routines.

Things such as dpkg-ftp, and dpkg-mountable are designed as an interface
between dselect and the packages on another filesystem or remote host. 

The absolute core of any system based on .deb packages and using the
current dpkg database system are going to need at least the first level of
programs to access these databases without extensive reinvention of
wheels. The dpkg executeable is not MANDATORY in a very strict sense of it
being a binary that calls the core function but it should be included in
teh core if only to give a manual method of fixing things should something
go wrong.  It is the fourth layer that can be left out of core.  There is
no need to put dselect or deity in the central core system though it can
be in SEUL-base for the SEUL distribution.  This allows another
distribution to create their own user interface that displays and manages
user selection and package browsing.  These programs would call to the low
level libraries that actually perform the manipulation of the packages.

The point of the package selector/manipulator is secondary to core
installation since it is not called until the real core of the
distribution is installed ... i.e. the selector can not install itself ...
it must get onto the disk in some way and the dpkg libs must also exist on
the system before it can even be used.

So what I am getting at is that there are really two cores ... there is
the SEUL-linux core and the Distribution base.  The core is integrated
into the distribution base and can not be easilly separated from it
without manual installation of the distribution specific items.  In a
real-world install, the core and the base will likely be copied to the
target media at the same time. At some point, control is passed from the
install media to the base (which is built on the core) which includes a
distribution-specific package selector or the defualt selector (deity? or
dselect) where the rest of the distribution is bootstrapped onto the
media.

This even allows you to have NO selector! At install time, it could ask
you to select from a list of pre-selected installs (1. GUI-Desktop 2.
GUI-Server 3. Network Server ... etc) and simply make dpkg calls to
install a canned suite of packages all preselected for that configuration.
Additional modules could be added in a distribution-specific manner ...
insert floppy ... system looks for a certain file ... if it finds it, it
begins installing packages to modify the system.  This allows one to
produce a "Acme Software Mail Server" CD-ROM for the Acme Software Linux
Operating System.  Of course, you would probably have to get the "Acme
Software Server" upgrade first :)

So you do not need a package selector so that should not be in core BUT
you DO need manipulation of the database structures so you DO need the
libs and you do not REALLY need the dpkg command but as a matter of
practicallity, it should be included in the core if nothing else but to
give support personnel a method of manually manipulating things.

And yes, this was short :)


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.