* Peter Tribble <[email protected]> [2009-08-25 19:41]: > On Mon, Aug 24, 2009 at 10:25 PM, Stephen Hahn<[email protected]> wrote: > > * Peter Tribble <[email protected]> [2009-08-24 20:19]: > >> 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.
I guess we disagree: the administrator can choose which versions are installed; if a site chooses to override the selected link, by delivering alternate packages, they can do so. > >> 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. Actually, I am also taking into account the customers with service agreements for Sun's product. Choosing to depart from the installed configuration is a site-specific choice, but changes one's expectation of servicability. I suspect we also disagree about what party has ownership of the components in /usr/bin and their interrelationships. > Allow for the fact that the "right" default version may be neither the > most recent or the highest numbered. We improve upon the current situation by allowing project teams to separate the identification of the default from the initial delivery of the version. As a result, a project team can choose not to deliver a verexec.d symbolic link, and delay advancing the default. > Allow the user/administrator to define the default version for each > application. (The current implementation allows sites to override the default version via the special "site" link, although I wouldn't be highlighting that in the documentation.) > 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 scenario is out of scope for verexec(1). > 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. The distribution's use of verexec(1) will be to manage default language platforms in /usr/bin. Other software producers may elect to use it for managing their multiply versioned, simultaneously installed components. Sites may choose to not use those platforms, presumably by providing their own local versions in alternative locations. - Stephen -- [email protected] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
