on Fri, Nov 17, 2000 at 12:07:53PM -0500, Walter Tautz (wtautz@math.uwaterloo.ca) wrote:
> I am curious to know whether it would be possible to have
> two or more version of a given package exist compatibly and
> have the alternatives tool be able to pick one.
>
> REASON. Sometimes the features of one version are so annoying that
> one isn't interested in the `newer' version. I suppose most people's
> answer would be: put the older version in /usr/local?
>
>
> One problem with having multiple version of a given package is
> the fact that common filenames would exist. How to resolve this?
> I see one solution:
>
> Put the files of a package in its own directory and then add links
> via the alternatives tool into /usr/bin/ /bin/ etc. It would also
> be convenient if the individual user could control what version
> he has access to by creating his own internal alternatives link tree.
This gets at a fundamental filesystem standards layout philosophy
discussion. I'm not saying your idea is bad, wrong, or unworkable, just
different from the traditional Unix/Linux standard. Within Debian,
'stow' provides a similar functionality, and you might be able to
achieve what your're looking for by using 'alien' or simthing similar to
un-debianize a particular package.
I believe MacOS and (possibly) OS/2 had a similar system for managing
software installs, if not versioned installs, in which different
packages essentially become their own tree. The Legacy MS Windows
system of placing software under a specific directory by vendor and
product name has certain similarities, though Legacy MS Windows DLL
management probably isn't a standard (?) to be encouraged. There's also
the Unix/Linux standard of /opt which might provide some food for
thought.
As I understand, instead of:
/
|-- bin
|-- etc
|-- lib
|-- sbin
|-- tmp
`-- usr
|-- bin
|-- include
|-- info
|-- lib
`-- sbin
You might want something like:
/
|-- bin
|-- etc
|-- lib
|-- sbin
|-- tmp
`-- usr
|-- doc
|-- man
|-- local
`-- <package+version>
|-- bin
|-- doc
|-- include
|-- info
|-- lib
|-- local
|-- man
`-- sbin
> Some consequences:
> =================
>
> How would apt figure out to update or upgrade packages... presumably it
> would simply offer to install the latest version without interfering
> with the version you have on the system...you could also perhaps choose
> to upgrade existing versions...
Adding a "install this version of foo" option to apt would be a Good
Thing(tm), though it might take some infrastructure changes.
> This brings up an obvious problem that people would be forced to
> maintain more than one version.... Also is it possible for the
> alternatives package to work for the user. Obviously the user could
> use aliases if he/she wanted to use a particular editor but it might be
> nice to have the alternatives tool not just work on a single system but
> on a per user basis.
How about $HOME/.alternatives or $HOME/etc/alternatives as an analog to
/etc/alternatives?
> Comments?
Yes <g>.
--
Karsten M. Self <kmself@ix.netcom.com> http://www.netcom.com/~kmself
Evangelist, Zelerate, Inc. http://www.zelerate.org
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
Attachment:
pgpGmcee02BHO.pgp
Description: PGP signature