[Mentalunix-developers] mpkg spec<plain text>

[Clinton E. <men...@ya...>]

Here is the mpkg spec in it's entirety, undedited,
unformated, uncensored. I suggest that everyone get
the Rich Text or AbiWord verison, because they are hte
only ones that look like it is supposed to(the html
version comes close, but lacks formatting and fonts).
Well, here is the 15K behemoth:

The MentalUNIX Packaging System
Specification Paper Revision 0
July 17, 2000 CE
AUTHOR: Clinton Ebadi



OVERVEIW

The MentalUNIX packaging system will be an
evolutionary step in Linux/UNIX packaging systems. Why
merely an evolution of existing package managers and
not a revolution? Simply put, it will only improve
upon existing technologies, while offering a few
simple, yet important new features. Until Now, you had
very few choices in package managers for Linux; The
Red Hat Package Manager(RPM), and the Debian Package
Manager(DPKG). MentalUNIX will bring a third, and
powerful competitor to the table: The MentalUNIX
Packaging System, or MPKG for short. It will offer
unparalleled ease of usage and an amazingly robust
feature set, in a small, efficient piece of software.
It will be free software, in both the "free beer" and
"free speech" meanings of the word, and will naturally
by protected by the GNU GPL. The MentalUNIX linux
installer(MentalUNIX linWiz) will be based upon mpkg.
MPKG will be available as a command line tool, and
ncurses based console-GUI, and a Gtk+ based X GUI.
This document will outline all of the features of the
MentalUNIX Packaging System in detail(although not in
the first few versions). 

COPYRIGHT

This document and all subsequent revisions are
(c)Copyright 2000 Clinton K. Ebadi and MentalUNIX. 
Distribution is governed by the GNU Documentation
License(avaialbe at http://www.GNU.org). It may be
freely redistributed, quoted, published and used as
long as this copyright notice of present, and the
document remains unchanged.

FEATURES

MPKG's will have many different features. The main
features are:
	-The ability to track installed software via a
package database
	-The ability to convert GNU autoconfigure and
automake into the native mpkg configuration files
	-Package configuration through XML files
	-Source and Binary Packages(with source packages
being the default format)
	-Scriptable package interfaces using javascript and
XML
	-Complete Source code availability
	-Simple, easy to use, yet powerful interface

These features will be outlined in further detail in
different subsections. 

	BASIC FEATURES

The MentalUNIX Packaging System has many different
features. Many of the features will be covered in this
section(but not in very much detail yet). The basic
features of mpkg(or any package manager) are the
ability to install packages, manage packages, keep
track of installed software on a computer system, and
configure packages. 
Package installation in mpkg will be as simple as with
rpm in auto mode(modes will be explained later). To
install a package in auto mode, a user simply types:
mpkg -Uvh --auto <package name>
Regular(interactive) mode requires the user to answer
a few questions to configure the package. The
command-line syntax will be similar to the Red Hat
Package manager(RPM), with extra mpkg only
commands(--auto is an example), and deviations from
RPM meanings(to make the arguments more intuitive). A
Package database with descriptions of packages,
package names, version information, and more will be
stored to make maintaining packages simple. The
database will be queried using:
mpkg -q <package short name>
A package short name is the name of the software(i.e.
"After-Step"), instead of the package name(i.e.
"After-Step-1.8.2-5mdk5"). The -q argument will simply
print the package name/version information, or give
the message "Package Not Installed" if the software is
not present. Package database management will be
covered in detail later(I could almost make this the
man page ;-).  Package configuration will be the
strongest feature in mpkg. Instead of distributing
precompiled binary packages, the preferred format will
be source code packages. Binary packages would be
allowed for special purposes(installing software on
lower end computers, installers, etc.). MPKG will
include a way to package source using only a source
tar-ball and GNU auto-configure and auto-make scripts.
The configure shell script will be used to generate
configure.xml, and will generate the make.xml file for
compilation. Packages will also have interface defined
in interface.xml. The package can use the
interface.xml file to execute javascript, load images,
and to modify the configure.xml file. The interface
*MUST* at the very minimum have a section for
configuration. If the package creator does not decide
to include the section, the configure.xml file will
define the interface(but it would probably look nicer
if it was created in interface.xml -- in addition, the
configure.xml won't be able to include supporting
text). Now that the basic features have been touched
upon, a detailed explanation of each of them will now
follow...

MODES

Earlier in the document, interactive and auto mode
were touched upon, but not explained. To fully
understand how revolutionary mpkg is, these "modes"
must be understood fully. The auto-mode is nothing new
to linux, since it is non-interactive. But the
interactive mode opens up a whole new world in package
management. Interactive mode allow the user to
interactively select options for compile time. The
interfaces can range from simple, one screen ugly
web-like pages, to simple interactive wizards, all the
way to extremely advanced XML/TCL/PHP/javascript-based
graphical setup programs(Imagine the linux kernel
xconfig program, run from the kernel source package).
As you can probably tell, this is very exciting. ANY
application will be able to be set up using
mpkg(assuming the developer decided to write a mpkg
interface/config.xml file). From a simply "hello
world" program to the linux kernel and beyond.
MentalUNIX linux will use it as it's only packaging
system during development. But, auto mode is equally
powerful. All programs will be required to contain a
config.xml file(optionally generated from a GNU
autoconfigure script) that specifies all the possible
options, the defaults, and other required
information(dependencies will be handles by
depend.xml). In auto mode, the defaults are
selected(except for things such as CPU type), and the
package is compile(and then installed). It may seem
simple at first, but what if it could recompile EVERY
SINGLE LAST package on an entire system! Yes, that is
what mpkg will be able to do. This increases the
development time for mpkg, but it makes developing an
entire linux distribution much simpler. Want to port
to an alternate architecture? With rpm, you usually
need a box using that architecture. With mpkg, you
simply set the destination to the platform you
want(say, PPC), and then it recompiles the entire
system for that platform. If a package fails to
compile(inline assembly, reliance on the endian
structure), then you know exactly what packages
failed. It won't just stop at the first failure. Of
course, you would need the development tools capable
of compiling for the target platform.  The next two
sections will explain in detail a small portion of
these two modes(more will be added later as it is
finalized).

	AUTO MODE

In auto mode, mpkg acts just like any other package
manager. You simply invoke the mpkg command you want:

	mpkg -Uh -vv --auto <package name>
This will Upgrade the package, install it if it is not
installed(The U command unconditionally upgrades, that
is, it will upgrade the package even if it is not
installed, but it will not install if the current
package is newer). The 'h' option display hash marks
as a status indicator, and 'vv' displays debugging
information. This will install the package without
loading the interactive interface. The config.xml will
include the default option(s) to be enabled, and they
will be used. But, if the package was already present,
it will query the database for the options that are
enabled, and attempt to use those(if they are not
present, then whatever existing configuration that can
be used is used). So, if vim was compiled to have an X
interface, it would still have that interface. The
MentalUNIX installer will use auto mode in for package
installation. Many people may think that auto mode
cannot allow any configuration of the package(aside
from the pre-installed configuration). But, that is
incorrect. Take this command:

	mpkg -Uh -vv --auto --opt-emacs_interface=yes
TiMidity.mpkg

This would install Timidity++ using auto mode. But
notice the 'opt' option. This allows the user to
manipulate the values in the config.xml file. By
invoking '--opt-variable_name=value', the user gains
the ability to set any variable in the package. But
what about multiple options? well it's as easy as
typing
'--opt-variable_name=value--variable_two=value_2'.
Simply, eh? Not very simple to parse, but ease of use
is the most important part of mpkg! Even if it means
adding a few extra weeks to development time, or
having the software become slightly larger. Mpkg will
not be bloat-ware, but it will be feature rich. Next
up is the interactive mode.

	INTERACTIVE MODE

Auto mode would make mpkg a decent package manager in
it's own right, but mpkg isn't just going to be
decent. It is going to be revolutionary. There are
already too many competing package managers out there,
so there is no reason to add yet another mediocre
package manager. To a newbie, installing software from
a tar file is confusing(even though it is truly
simple). RPM files may not be optimized for their
computer, resulting in a negative experience with
linux. Mpkg will include all packages as configurable
source code packages(although binary packages will be
allowed for situations when using source is not
possible or not attractive). The interfaces to these
packages can range from simple(one page interfaces
generated from the config.xml file), to beautiful
wizards. It will be a way to build installer with a
minimum of knowledge(XML is all that is required).
Using special mpkg DTDs, with configuration and
interface syntax(buttons, images, text fields,
paragraphs, etc), mpkg will allow anybody with a text
editor(you will be assimilated...resistance to emacs
is futile) to create amazing installers. In fact,
using TCL, php, and/or javascript, complex
applications may be created(think the linux kernel
xconfig program). These interfaces will be
display-agnostic, as will mpkg. Mpkg will communicate
with a display back-end that will handle the real
graphics work. This will allow the creation of console
and X based interfaces much easier. How will mpkg
implement a complex XML parsing engine, with support
for TCL, php, and javascript? One word: yozilla. The
gecko/bender rendering engine will support all of
these technologies(except for php, which is normally
processed server-side, but will be implemented using a
plug-in). Of course, yozilla will use libxml. The
protocol over which they will communicate has not been
decided, although gecko/bender will be a shared object
library(allowing mpkg to be dynamically linked to it).

Defining an interface is simple. Here is a skeleton
interface.xml file:
	[xml header stuff, xml tag, call to DTD, etc]
	<var> <!-- assorted variables -->
	<include config.xml \> <!-- We have access to all of
the data in 
	config.xml -->
	</var>	
	<interface> <!-- We now define the interface -->
	<page=0> <!-- The first page, or page 0 -->
	<object type=button kind=shadow.text text="test
button" pos=64,64 \>
		<!-- Now we have a shadow button, at x=64 y=64 -->
	<object type=button kind=bevel.image img-type=xpm
src=b_img.xpm 
	height=50 width=150 pos=100,100 \>
		<!-- Now we have a beveled image button. The button
is 4 or so
		pixels bigger than the image by default, but a
thicker border can
		be defined...there is an image.text button too -->
	</page> <!-- Page 0 is over -->
	</interface> <!-- No more interface -->
	</xml>
Of course, the example was poorly formed, and no xml
interpreter would process it. But, I hope that you get
the general idea. The ability to define these
interface allows a programmer to design an installer
for their program in less than a day(sometimes in
under a half-hour). For a packaging system, mpkg may
look like it has too much power, and will be
bloat-ware. But, with the apparent lack of any good
install tools for linux(this includes Zenguin...which
has apparently died). And, mpkg itself will be very
small, and will use the gecko/bender rendering engine.
Just imagine a future where package installation and
unistallation is easier and more graphical under linux
than any other Operating System. 


	THE PACKAGE DATABASE !NOT FINALIZED! HAS NOT BEEN
REVEIWED BY OTHERS

Without a package database, what is the point of a
package manager? The answer is, there is no point! 
That is why mpkg provides a package database. One of
the nice things about the database is that it will
operate on the principle of package ownership. Every
file on a system must be owned by a package. If two or
more packages need a file, say foo.so, then all the
packages 'own' it. This way, when a package is
un-installed, instead of failing, a warning message is
issued that other packages share the ownership of
foo.so, and it will not be removed. So, if you decided
to un-install yozilla, but wanted to keep mpkg,
bender.so(The rendering engine) won't be removed, but
the rest of the program will be. So, instead of having
all or nothing, you can keep the parts of the packages
that you don't need, but other programs need. The
database will either be served by an SQL
server(unlikely) or using a flat XML database
file(parsed by gecko/bender and then interpreted by a
database module of mpkg). The database will also
contain programs not in mpkg format. How? Mpkg will
ship with a database of known existing programs, and
common locations where they can be found. A daemon
will keep track of whatever happens to important
directories(for example, /usr and /lib). Whenever a
binary is added, its file name will be checked against
the database to see if it is known. If it is,
mpkgd(the mpkg daemon) will add the new program to the
mpkg database. More on the database will be published
as it is finalized.


	/OPT/MPKG/<PACKAGE NAME>

Why is a directory name the section header? Simple,
it's another reason why mpkg is
revolutionary(err...will be). After a package is
installed, a directory for it will be created under
'opt/mpkg'. This special directory will contain
symlinks to all of the programs files. All of them.
Libraries, documentation, binaries, source code, etc.
It may seem simple, but it allows an administrator to
quickly see what files a package 'own', without
invoking mpkg. Since querying a package in the
database for the files it owns can be time and
resource consuming(especially for large databases),
this is a simpler way. This also provide
pseudo-centralization. Programs are still scattered
into different directories(great for system-wide
centralization, but not good when you need a program
all in one place), but you can access all of the
programs files from one place. More will be added as
it is finalized.


	COMMAND LINE OPTIONS

Argh! I didn't have time / was too lazy to put this
section is. Well, here are a few. Can somebody,
anybody, everybody get the...errrr....help with this
part of the spec?

	-U Upgrade / install if not installed
	-i Install. Will fail if program is already present.
	--auto Auto mode
	--opt-var_name=value /
--opt-var_one=value;var_two=value;etc Pass an option
to the config.xml file in auto mode.

More will come when people start helping.


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/