[ On Friday, February 11, 2005 at 09:59:56 (-0500), Todd Vierling wrote: ]
> Subject: Re: pkg_alternatives as a dependency, again
>
> On Fri, 11 Feb 2005, Greg A. Woods wrote:
> 
> > The whole idea of trying to give a common name to some alternative
> > package with a scheme like pkg_alternatives is totally bogus from the
> > get go.
> 
> Maybe to you, but not to a lot of users.  It helps system maintenance tasks
> that otherwise would require...
> 
> > login shell features or similar.
> 
> ...something which is nice to automate.

I don't really see the connection.  Not all the alternatives I mentioned
require a login shell -- they're just the things I'm most familiar with.

>  I was skeptical at first, too, but
> after deploying it on a few heterogeneous systems myself, I'm hooked.

How is it different, and in particular how can it be better than, a very
simple wrapper script scheme that explicitly works to avoid name
clashes (instead of effectively causing them)?

Wrapper scripts, symlinks, etc., are also, BTW, quite usable without
ever having to use a login shell, and they are of course extensible to
solve all the miriad of problems that pkg_alternatives can never even
dream to approach (except in cases where bug-for-bug compatability was a
design goal, e.g. as with nano, alternative pacages are never 100%
compatible, even on the command line, with what they hope to replace).

Do you have solid generic answers to these inherent conflicting
priorities issues that a more limited scheme like pkg_alternatives
obviously suffers from?  Solutions that'll work 100% with binary
packages?

Can you give more concrete examples of where you've found pkg_alt's
something to get hooked on and which don't involve login shell use?
Can you show how those examples are better done with pkg_alt than they
could be with explicit wrapper scripts or symlinks?

-- 
						Greg A. Woods
						Planix, Inc.

<woods@planix.com>     +1 416 489-5852 x122     http://www.planix.com/