On Mon, Aug 24, 2009 at 10:25 PM, Stephen Hahn<[email protected]> wrote:
> * Peter Tribble <[email protected]> [2009-08-24 20:19]:
>> On Sat, Aug 22, 2009 at 12:03 AM, Stephen Hahn<[email protected]> wrote:
>> >
>> > Please read
>> >
>> > http://blogs.sun.com/sch/entry/verexec_1_a_simple_execute
>> >
>> > for some background, and then review
>> >
>> > http://cr.opensolaris.org/~sch/on-verexec/
>> >
>> > I'm debating implementing some of the refinements mentioned in the
>> > blog entry, as well as providing manual pages for both verexec(1) and
>> > isaexec(1).
>>
>> The question that immediately comes to mind is: why would
>> one want to do this?
>
> The blog post explains the background reasoning.
Which I had, of course, read thoroughly.
>> We're still struggling to get rid of the Slowaris moniker, and adding
>> more slowness really doesn't seem like a good idea.
>
> We're in the "env perl" path; the current approach to installing
> language platforms like Java, Perl, Python, and so on means that a
> path for each specific version is also delivered. Sites that find
> that they have performance reasons for using that path have one
> available--I would argue that such paths should be used since these
> languages tend to have version-to-version incompatibilities.
>
>> Also - and this is the thing I hate about these schemes - it changes
>> the execution of programs from deterministic to guesswork. The version
>> you get is essentially random (from the point of view of a user).
>
> Random? Really?
>From the point of view of the user and administrator, yes. There
is logic ("magic") going on behind the scenes that they have no
immediate visibility of, and no true control over, leading to
behaviour that differs over time and space.
>> In what way is this better than a symlink to the right version? Not
>> only is it then immediately obvious (from ls) which version is
>> invoked, but that also allows administrative control of the "best"
>> version to use by default (which will not always be the most recent
>> one - I invariably have new versions installed for testing well ahead
>> of their becoming the normal version).
>
> Please read the blog post. (Or, if you like, consider how you would
> manage your symbolic link with multiple packages potentially
> delivering it with different targets.) verexec(1) is intended for the
> interpreters or virtual machines delivered by the OS for its use, so
> we wouldn't generally consider development interpreter versions here.
This is just one small part of the general question: how do you ensure
that, if there multiple versions of a piece of software installed, the user
gets the "right" one. To solve this:
Please take the users and adminstrators needs into account, rather
than simply worrying about making the packaging system easier to
implement.
Allow for the fact that the "right" default version may be neither the
most recent or the highest numbered.
Allow the user/administrator to define the default version for each
application.
And the scheme must also allow for suites of software (think KDE
or GNOME as extreme examples), so that a different version of that
suite can be selected. The interesting thing in this case is that the
list of programs in each version is different.
This is a problem we deal with all the time, and judicious use of symlinks
and appropriate setting of PATH variables solves it nicely. Adding verexec
would make it much harder to manage systems in a consistent fashion.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
