[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Package format/management ramblingss
From: |
Richard Stallman |
Subject: |
Re: Package format/management ramblingss |
Date: |
Fri, 30 Jul 2004 00:55:14 -0400 |
Yet another problem are conflicting versions. In Debian, for example,
two different installations normally conflict. As a compromise,
unstable development versions, for example, are provided as separate
packages.
Every problem of this kind is solvable, but a solution does not exist
in all cases; so a *general* system-wide and program-independent
solution would be desirable.
There's an idea in my proposal for this: The symlinks from /packages
that cause a package to virtually appear in /bin and elsewhere can
have names that virtually rename the executables in the package.
My idea is that these executables would get the other files
of the package out of the directory that the package is really
running from. That way, multiple different versions could coexist.
It is the same problem
if you have a (physically :) portable computer and work in two separate
networks with it and need independent configurations but do not want to
install a new system for each environment.
We could imagine using special names for the symlinks in another way
to help address this problem. They could associate the various
installed versions of a package with different configurations.
By selecting your configuration, you could control which installed
packages "show up" virtually in files in /etc and its subdirectories,
Thus, /package/address@hidden -> /disk/foo-a and
/package/address@hidden -> /disk/foo-b would set up for configuration
variable foover to control which of these two gets installed. Set
foover to hay, and you get foo-a. Set foover to wow, and you get
foo-b.
You could, as every user else on your system, act in a kind of chroot
environment and compose your own user-specific directory tree!
Do you mean something like /package/foo -> /disk/foo-$foover? Then
you would set configuration variable foover to either a or b? That
could be a good feature. We could combine the two by using $ in the
symlink's name, too: /package/address@hidden -> /disk/foo-a, for
instance.
2. Also desirable would be the feature of ``preferring'' symlinks,
which especially becomes interesting with the feature of directory
merging:
This could also be a good idea. How would you specify preferences?
Here's my idea: make a subdirectory in /package called
/package/conflict-resolution. In that subdirectory there would
be ordinary files, and each file would have a list of package names.
If one file said "foo bar", then foo would be prefered to bar
in the event of a conflict.
Normally, the conflict would be treated as an error. The system
should not silently resolve conflicts; it should warn the admin. The admin
would then choose how to resolve them.