Messages in this thread |  | | Date | Fri, 31 May 1996 15:03:01 +0200 (MET DST) | From | Michel LESPINASSE <> | Subject | packages and the kernel (long, sorry...) |
| |
I would like to talk you about the way the user has to handle packages on a linux system...
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--------------------------------------------------
|  |