On Wed, Dec 03, 2003 at 11:06:29AM +0100, Michel Schinz wrote:
> Anthony Carrico <acarrico@memebeam.org> writes:
> > 1. NEGATIVE -- everything is not in one hierarchy...
> Like Mike pointed out, it is indeed very practical in the Unix
> context, with the help of symbolic links.
Thank you for the links, and I did follow them up. I see your point,
and I could imagine using something like stow or package views
locally.
> > 4. NEUTRAL-POSITIVE -- Note that still only one symbolic link (foo ->
> > foo-1.0) is necessary for the "active" version feature. This design
> > does not required programmers to add any extra directory levels when
> > using the active version of the script (to load active use:
> > foo/load.scm to load versioned use: foo-1.1/load.scm).
>
> Indeed, that's another way of designating the "active" version of a
> package (it's in fact the one we use here at work, as explained
> above). I originally chose the other one with an "installed" and
> "active" directory as I felt that it provided a better "separation of
> concerns", so to speak. But I have no strong opinion in its favour.
As you said in the original proposal:
> (This relies on the fact that both the "active" and the "installed"
> directory are in scsh's library directories).
I think there is some advantage to getting rid of this redundancy. It
seems a little cleaner, and maybe there would be some performance
advantage, since the search list will be half as long.
> I think we should try to find a solution which accommodates both uses,
> because both are common. Packaging systems work well for single
> machines, and when the user has root access to it, but as soon as you
> have to manage a large network of machines, it is usually far easier
> to install software on one central server. This makes most current
> packaging systems unusable.
and
On Tue, Dec 02, 2003 at 09:50:40AM +0100, Michael Sperber wrote:
> AC> 1. NEGATIVE -- everything is not in one hierarchy.
>
> Well, as long as it doesn't all have to be under /usr or /usr/local,
> it still can be.
If I understand Michael's point, he means that if you don't use /usr,
then my proposed tree all ends up in a single directory as you like --
does this constitute "a solution which accommodates both uses"?
> One solution could be to provide an installation library which can
> perform the two kinds of installation. The installation script could
> be passed an argument to specify which kind of installation to
> perform.
An advantage of using the same relative layout for both the "all
packages in one tree" and the "one tree per package" camps is that the
package itself can always find its resources. Why introduce gratuitous
incompatibilties?
If the two camps had different subtrees, then such installization
customization is required for the two different layouts, but by
choosing a "standard" layout we can avoid such customization for most
installations in either camp (the only difference is if the
installation's root directory is shared or not).
[It has been pointed out to me that standard I looked at is
Linux-centric, but I imagine the bits I've followed are pretty much
the same across most Unix platforms, right?]
--
Anthony Carrico
|