On Fri, 11 Feb 2005, Greg A. Woods wrote:

> > 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.

> 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)?

What type of scheme would avoid "name clashes"?  The point of
pkg_alternatives is to have an entrypoint that has a command name users
already know.

> 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).

Nope, they're never perfectly compatible.  That's not a requirement of the
alternatives system.  One such alternative that will become quite useful,
for instance, will be to give a nroff frontend to cawf as an alternative to
groff.  That doesn't mean they really are fully compatible.

> 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?

You haven't explained what these "conflicting priorities" are, or in what
way you see pkg_alternatives as "limited" (within the scope of
pkg_alternatives's design goals).

Note, too, that I don't use the full set of pkg_alternatives's functionality
either, and I don't necessarily plan to do so.  Features other people like
don't necessarily reflect what I like, and vice versa.  It seems fine to me
that pkg_alternatives implements a common superset of both.

> 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?

Should I?

That said, yes, I have already run into one place where pkg_alternatives
would be most helpful:  overhaul of mailwrapper for use with postfix vs.
sendmail vs. exim vs. (etc.).

> Can you show how those examples are better done with pkg_alt than they
> could be with explicit wrapper scripts or symlinks?

Here's where it gets interesting.  I had suggested use of simpler wrapper
scripts for consistency, but there is a point behind the current
implementation.

The more robust scripts used by pkg_alternatives today implement an
iterative fallback scheme and user preferences, neither of which I use (my
alternatives are all using just one implementation system-wide.  For
"interactive-class" applications, this sort of thing seems perfectly fine to
provide, as it can cater to user desires where wanted.

For applications that are typically invoked as data processing tools,
however, user configuration isn't necessarily desired.  This breaks
completely for interpreters using #!, as has already been demonstrated.  I
offered a fix for that earlier in this thread (classify these as
interpreters, requiring a symlink and only system-level changeability).

That doesn't mean I'd want to see everything switched to symlinks.  Some
tools are not necessarily interactive, but have real-world user preference
needs (the Java class of programs comes to mind).  So, if we just have an
"interpreter" class using symlinks, and default the rest to user-choosable,
this should resolve our extant problems.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>