[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[RFC] managing dependencies with levels



Hello,

It's probably a bit off topic, but this might be of some interest for
others.

As explained in a previous thread, because I have special and urgent needs,
I am building an installation system whose destination is to handle the
automatic installation of a core system (and being independant from the type
of kernel etc...).
I use BB compiled against uClibc, ash (0.2) compiled against uClibc too, and
have written a Bourne shell script (10 Ko with comments and unzipped) that :

o retrieve the information about the package servers it is allowed to
contact
o retrieve the information about the resource server it MUST contact
o check the signature of the packages downloaded by contacting an
authoritative server
o customized the package, whether interactively or not
o and install them

This all with tftp or wget, sed, tar, gunzip, md5sum etc... that is what 
BB gives us.

The main goal being to have the simplest tool to install, the biggest
problem is how to handle the dependencies.

I use a package format of my own, and had, last night, the following idea to
achieve the goal.

Perhaps do you know the types theory of Russel and Whitehead, specifically
designed to avoid the vicious circle antinomies [the theory by itself is not
my cup of tea, but it matches what is needed]. The idea is simple. A "level"
is computed at package creation time with the following principle :

level of package = max {level of dependencies} + 1

The level 0 is special : this is the core system (must be minimal). A
statically linked executable is level 1 (depends on core system and that's
all), ld.so is level 1 too. libc.so is level 2 (depends on core and ld.so).
Dynamically linked executable are at least level 3, etc...

The install tools simply has to install packages in increasing level
numbers. All packages having the same level can not, by definition, have any
circular dependencie, since this will mean that they depend on a package of
the same level thus that they have at a level of a greater value.

When a package of a lower level is not installable, the packages of higher
levels are discarded. If the packaging tool is unable to give a Level, then
there is a problem and the package is not installed if Level is not set.

Secondly, in order to manage version with "small tools", I have the idea to
convert a "quad dot" notation in a integer, the same way IP are handled :

1.9.3.4 => 17167369

and then handle that simply with -eq, -lt or -gt etc... This stuff being
made by the packaging tool, not at install time.

Any comments ?
-- 
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: