Re: Package format/management ramblingss

[Richard Stallman]

       The problem is that one would have to configure all the programs to
       expect a version number after their configuration and data
       files/directories, even in user directory. 

This is unnecessary.  Whichever version you run will be given a
pointer to the directory it is unpacked in.  It will find all its data
files there.  User configuration files could cause problems but only
if they are incompatible in format between versions.  We hope that app
developers will avoid that.

       Which package is allowed to put files where?

    A package is _only_ allowed to put files in /packages/PACKAGE.  It is
    a package after all.

My idea is that you can unpack a package tarball anywhere you like.
When you symlink to that directory from /package/SOMETHING, or from
~/packages/SOMETHING, it becomes an installed package.  The name of
the directory itself is irrelevant.

We have been making a habit of supposing that these tarballs
are unpacked under a directory called /packages, and that could
be a good convention to follow most of the time, but it is not
a requirement and there is nothing special about /packages.

       Should we allow other packages to put files in /share/emacs?

    No package will put files in /share/emacs, that directory is a virtual
    one.  /share/emacs would be the union of /packages/*/share/emacs.

I don't think this makes sense.  We don't want to produce /share/emacs
in this way.  We might want to produce /share this way, and emacs
would contribute the subdirectory `emacs' to it.  But I think the
right solution is not to use /share/emacs at all.  All the files that
might have gone in /share/emacs should be in /packages/emacs-20/etc,
/packages/emacs-20/lisp, and so on.

When Emacs starts, it will be able to open names like /dev/mydata/etc,
/dev/mydata/lisp, to get at those directories.

It would be tempting to replace /dev/mydata with /share, so that
Emacs could open /share/etc, /share/lisp, and so on.  But I think
there will be some things that really need a /share directory,
so this would get in the way.  It will be more reliable to use
/dev/mydata.

This has the advantage that different versions and different programs
don't get in each other's way, and that installation and
deinstallation are trivial, and that moving the unpacked package's
directory has no effect as long as the symlink to it gets updated.  It
is 100% clean.