Messages in this thread |  | | Date | Sat, 1 Jun 1996 23:13:12 -0400 (EDT) | From | Kevin M Bealer <> | Subject | Re: packages and the kernel |
| |
On Fri, 31 May 1996, Albert Cahalan wrote:
(clip) > > 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). >
You are putting files in a -directory- to keep track of -which package- they are in, so you need to keep files to track what they do (ok so you are sticking the same info into inodes) which is equivalent to 'where they go'.
Turn it around.. Put them in directories that tell where they go (and what they are) and keep a file (or in inodes) that tell what they are. --- And you have a distribution again.-- you're not really gaining anything. ----
Kernel side : if you are going to use the kernel, keep track of all package files by what 'package' they belong to in the same way you track user/group.
Now, you still need distributions, but:
Rules: 1. A file created by standard methods would belong to the package the executable creating it belongs to --- nothing currently existing will break. Some directories would be exempt, ie mail spools and home directories, which could be set with a permission flag.
2. files made by login shells belong to a 'package' of the user's name. (this won't get used much, except a user can be 'packed up' from one system, and unpacked onto another (or maybe not..)
3. new file creation functions or fcntl stuff can be made to allow users to create files in a specific group (some permissions would be necessary).
-- > I can tie files to packages, so that the package's deletion kills the file.
Debian, redhat, etc would all still be necessary, but they can be made compatible. All that is required to remove a package, is to flush all files in that package. Information in inodes could optimize this some.
1* this should all probably be done in user-space first, as an extention to current dist. methods... the umsdos type kludge, with an eye for eventual kernel support.
2* this is unlikely.... too much inertia in current system of doing things.
__kmb203@psu.edu_________________________Debian__1.1___Linux__1.99.7___ The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
|  |