About stowfs dependency check

[Gianluca Guida]

Hi Alfred,

I spent some time searching (looking at the clock, the whole night)
for new ideas after the discussion about stowfs we had in #hurd. I cc
this mail to gnu-system-discuss in the hope that others may tell what
they think about the topic.

I still think that dependency checking is important to implement in
the translator (I said *checking* not *resolving*, that is it won't
download or search for missing packages). If we don't let the
translator be aware of dependecies between packages, the package
system will not be really usable from a simple shell without special
tools.
To be clearer, by having a very simple and dumb low level stowfs that
links and remove packages not caring about dependencies and shifting
these decision to higher level smarter applications, reminds me of
those fancy "user-friendly" GNU/Linux distributions's system scripts:
they work until you use the proper KDE tool, but when you go to shell
to make the dirty job you screw everything.

IMHO the stowfs translator, intended as provider of the lowest level
package management, should be designed to let the user do without
black magic what higher level application do and, at the same time, to
let the hackers force things (like forcing removal or ignoring
dependencies).

My ideas about how to achieve this follow. I hope it is useful.

What I mainly changed my mind about is what to do when an user links a
package that has unfulfilled dependency.
Suppose there's a package called 'bar' that depends on a package
called  'foo'; foo is currently not installed. If the user try to
install the package by typing:

# ln -s /packages/bar-0.0.1 /stow/bar

stowfs will check for bar package dependencies and will find that the
needed package bar isn't installed. As you stated, it is wrong to make
'ln' fail here, since the user didn't do anything wrong. What the
translator could do is to create a dummy foo package by linking a
special stowfs entry 'MISSING' to 'foo', like this:

# ln -s /stow/MISSING /stow/foo

On a formal way, MISSING is the virtual packages that fulfill all dependancies.

Now, let's face the case of package upgrade, e.g. we want to
substitute foo-0.0.1 with brand new foo-0.0.2:

We could do either:

# rm /stow/foo
(the dummy foo package will be created if other programs still need
the foo package)
# ln -s /packages/foo-0.0.2 /stow/foo

or alternatively, the equivalent but shorter

# ln -sf /packages/foo-0.0.2 /stow/foo

Similarly, to remove package foo

# rm /stow/foo

will do the job (and eventually creating dummy link).

To see the list of dummy packages, we could simply type:

# ls -l | grep MISSING

This is much similar to what you was describing on the inspirating IRC
talk, but, by adding a non-intrusive dependency checking, helps you to
see what is the real status of the system dependency and makes
possible to do high level package management without black magics, in
a (IMHO) clever and simple way.

I even have some idea about the versioning stuff, but i prefer to see
the feedback of this before bothering again (and btw, i'll soon take
the bus and go to uni!) :-)

See you,
Gianluca