Stephen Hahn writes:
> > > This means we need verexec:
> > >
> > > http://blogs.sun.com/sch/entry/verexec_1_a_simple_execute
> >
> > Interesting, although I see a couple of problems (and haven't followed
> > pkg-discuss due to its enormous volume). One thing is obvious, though:
> > even with verexec, you need a consistent schema how different versions are
> > installed in the filesystem, and the proposed installation of GCC differs
> > from the estalished scheme, which is also used by verexec: something like
> >
> > /usr/gcc/4.3/gcc
> >
> > instead of
> >
> > /usr/bin/gcc-4.3.2
> >
> > This is one of my complaints.
>
> verexec would only require that its link directory in
> /etc/verexec.d/gcc be consistent; those links could point into
> arbitrarily constructed trees, or whatever. That wouldn't justify
Ok, fine, though I think it would be beneficial to have a way to select (on
a component basis) something different from the highest version as the
default. E.g. if you deliver jdk 1.6 and 1.7 (not yet FCS), you would
still want 1.6 to be the default. But not this case :-)
> avoiding the /usr/[component]/[version] approach used, for example, by
> Perl and Apache for shipping multiple simultaneous versions.
Indeed: that is my familiarity argument here. Besides, this would help in
a case where verexec might have problems: what happens in a case when
version x doesn't deliver the zzz command, but version y > x does? With
hardlinks to verexec, you might get a different result than with PATH
pointed to /usr/[component]/x or /usr/[component]/y.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
