Re: di: seperate preperation and installation phases
On Thu, May 10, 2001 at 01:08:39AM +1000, Glenn McGrath wrote:
> Thierry Laronde wrote:
> >
> > BTW, I have designed a new packaging system, with a new package format, that
> > could be a proposal for a common basis for other packaging system.
> >
>
> Id be interested in hearing what you have in mind, do you have any
> details handy ?
I'm, of course, still working on it, but here are some sketches of the
directions I take.
General idea : you obtain "products" by applying `rules' to `data'. So the
package will always have a `rules' with, optionnally, data. But a package can
consist only of rules. There is no data without rules. This format allows
"task" almost naturally, but also to administrate by sending a package which
consists only of rules (i.e. commands).
In fact, a package is a tgz of a strictly compliant Bourne Shell script
named `rules' (probably also "or a Makefile") "explaining" how to handle
data placed in a subdirectory called... `data'. The format is defined to be
able to be handled by a minimal system.
data has the following constitution :
./data
|
|_RSC
|
|_BIN
|
|_CONFIG
|
|_DOC
|
|_INFO
|
|_MAN
|
|_SBIN
|
|_SRC
|
|_VAR
The subdirectories MUST be considered as variable or symbolic names. There are
two main files defining the system policy, that is `System.data' (defining
what are the actual value of DOC for example --- this can be /usr/doc or
/usr/share/doc ;) --- etc, defining the VERSION of the system, etc...), and
System.rules defining system dependant subfunctions for the installation
tool (at the moment, I work with the lightest and simplest possible, and
this is all ash compliant script, invoking BB commands).
The System.data allows to change the directories [these values are changed
by the way packages are installed ; untrusted packages will go in
directories prefixed by a "sand-box" directory ; a normal user can install a
package ; but no non-root can deal with the core system etc...].
The System.rules allows to customize the administration of the packages. For
example, if one decides to have a sysVinit style, this will be different
from a BSD style. A function to insert and run a daemon is different too. So
the packaging system defines a kind of API (a way to invoke a prototype, say
install_daemon) but the internal details of the function IS NOT defined in
the packaging tool but in the System.rules.
One of the more "interesting" directory is the RSC one : this is the
resource directory, which contains data used at installation time but not
installed as files on the system. For example, to customize a package, one
puts in CONFIG (which ordinarily will be /etc/$pkgname) files with, say,
##VARIABLE## strings. The file containing these installation time defined
values are suffixed .template. The default values of these are put in files
in the RSC directory, where the package tool can look in order to parse the
templates.
If none are defined -> interactive
If one wants to customize a package and distribute it, he just adds a
correct RSC directory to the tar.gz archive.
The format of the package file must match as close as possible an organization
of data in a tarball (the main package format is source ; in the system I'm
building, the system calls build daemons to customize the packages, and put
them in package servers, whose role is just to cache them).
The name of "binary" package are built with the version of the system they
match, and the architecture. If your version 1 is kernel_foo with
libc_bar, a system whose System.data is saying that VERSION is 2.0 will search
for binaries for that version and for the architecture. If there is none,
the system asks the build daemon to build the correct version. This is an
"ever upgrading" system [and this is theory; I have just started with the
bootstrapping OS].
A system invokes an authoritative server telling him what are the pkgserver
it is allowed to contact (the server sends back something closed to a
sources.list with the name/IP of the server, the directories allowed, the
protocole to use). The authoritative server serves also the signature
of the packages and, if a package doesn't match a signature given by the
authoritative server, even if it comes from an authorized server, the package
is not installed.
Updating the sources for the package is made by the package tool. At the
moment, I simply use tftp, and http (and local source), since these ones are
implemented in BusyBox.
I have more to say but will work in order to have "lot" to show, I think
during Debian Conference.
Cheers,
--
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org
PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org
Reply to: