lkml.org 
[lkml]   [1996]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.054 / U:5.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site