The only real problem is Unix compatibility. That's a big problem.
> 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.
The only one I know is DOS 6.x without Windows. Each app gets its
own directory, and the deltree command uninstalls apps. Even with
Win95, you have to trust that the uninstall program provided with
an app works. I'm sure they really cared to debug it.
> 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.
Yes, but then you get something off the net, delete some files,
whatever. Soon the provided tools won't work.
> 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.
No way.
> 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.....
The root filesystem is pretty much hardcoded, and it must work at boot.
Fortunatly, /usr can be hacked a bit.
Instead of marking all the files that get installed in random places,
install packages as you would in DOS. You can use an inheriting or
union fs if you really need to make something read-only or local.
Now, add symlinks to fake the unix directory structure and a tool to
clean out dead symlinks. Problem mostly solved. (some sites do this)
Here is where this relates to the kernel: eliminate the need for
symlinks. You can maintain a database of files that maps the path
to the purpose, then have a userfs that creates a virtual /usr from
the database. The most common tools (shell, window manager...) could
avoid any performance loss if you modified them to read the database
directly - somewhat like the Windows registry I think.
More radical: Have a filesystem that can be mounted with two different
directory structures, the package view and the user view. From the
package view, root installs software packages by putting each one in
its own directory. Root marks each file with a type (like the Mac).
Files marked as type bin automatically show up in /usr/bin and they
disappear when removed from the package view. You might have to give
up hard links, but that is a good idea anyway (for reverse lookups).