RE: [OT] Scripts, packages, etc.

Yes, allowing simultaneous installs of multiple versions,
and using links to pick the default one, is a great feature of /package.

Debian (and to a lesser extent Red Hat) does this, too; in those systems,
the links 
are in /etc/alternatives rather than /package, but it's the same idea.

They chose /etc/alternatives so the links would be in a filesystem that's
more or less local, so you can share the actual programs
across multiple workstations via a read-only remote mount, 
while allowing individual workstations to pick their own versions by
tweaking the links.
This doesn't seem to be supported by /package, which seems to mix
the links in with the real programs.  Or am I mistaken?
- Dan

-----Original Message-----
From: D. J. Bernstein
To: [email protected]
Sent: 23.06.2003 09:31
Subject: Re: [OT] Scripts, packages, etc.

Nicholas E. Walker writes:
> The /package mechanism allows one to install a potentially unstable
> version of a package without needing even to set it as the system
> 'default' (i.e. the one with commands linked into /command).

There's no reason for /command entries to link directly to versions:

   /command/multilog -> /package/admin/daemontools/command/multilog
   /command/svscan -> /package/admin/daemontools/command/svscan

Links to current versions are in /package:

   /package/admin/daemontools -> /package/admin/daemontools-0.76

What matters for the current discussion is that you can have, e.g.,
/package/admin/daemontools-0.76 and /package/admin/daemontools-0.80
installed simultaneously, with the /package/admin/daemontools symlink
determining which version is used.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago