When someone switches to a unix environment and starts to administrate
it, the way packages are organized always seems strange to him at first.
I can remember when I was a starter, and I always asked myself why some
package has to be divided into several directoryes - ie
/usr/local/bin/prog, /usr/local/man/man<n>/prog, /usr/local/lib/whatever.
Now that I'm a bit more experienced with this and that I've read the
fsstdn and so on, I realise that the value of this organisation. but
still, I'm not fully satisfied with it. It still lacks some features that
would be really useful in everyday's life.
For example consider the process of a libc upgrade : after installing a
new library with all its headers and such, you'll never be able to delete
the files in the old library that are no longer necessary. You can easyly
upgrade by adding and updating files, but you'll never delete anything,
leaving some dirty things behind you.... or you would have to reinstall
your system on a regular basis, a la microsoft, yuck :(((((
And it's the same with every program, you usualy can't be sure you
haven't left a peace of config file or manual page somewhere after
uninstalling.... I think it's really bad. In my opinion every good
operating system should provide a standard mean to install and deinstall
packages.
Probably you'll say that distributions are made for me.... (and btw, yes,
currently I'm running debian 1.1 beta and I really like it). In my opinion
these are a great step ahead, but it's not enough. the problem is too
much fundamental to me, and i think it should be treated with a more
general solution.
Basically I would like to be able to type something like "setpackage
libc-5.3.18" before my make install or my tar xvzopf, and the kernel
would remember for me that any new files it creates are part of this
package. This would allow for a much more generalistic solution.
I can imagine two ways to code this without bloating the kernel too much :
the first one would be to have the kernel notify a daemon each time some
user creates a file. Then the demon could be made aware that this
particular user is currently installing a given package, and note in a
database that the file is part of this package. The interface between the
daemon and the kernel could be implemented with a fixed-length queue, as
for klogd.
The other way would be to modify a file system so that he's able to
update this package database himself. Probably this would require a bit
more code in the kernel, but on the other hand it should be faster,
because this information would be stored directly with the filesystem
information. It shouldn't be so big as it seems first, because this file
system would only have to add package information in the filesystem (just
as currently it stores acces rights and the like), and all the
intelligent tools we want to have to handle packages would be implemented
as scripts running in userspace anyway. I fact, I really prefer this
second solution, I think there wouldn't be *so much* to add to get it to
work.
Now that's only the idea as I was able to imagine it, and I would like to
know if some people here find it interesting, or can you imagine a more
subtle way to handle packages in a general case, or should my scheme be
modified a bit, or.....
please let me know if it's something to work on or not :)
Michel "Walken" LESPINASSE - Student at Ecole Centrale Paris (France)
www PC demo coder & official LiGNUx support
(o o) Email : walken@via.ecp.fr
------oOO--(_)--OOo--------------------------------------------------