[ On Thursday, February 10, 2005 at 23:41:09 (+0100), Julio M. Merino Vidal wrote: ]
> Subject: Re: pkg_alternatives as a dependency, again
>
> How could we decide which package is the preferred one for a given
> alternative?

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.

If someone wants to get "vim" when they type "vi", then there are nearly
an infinite number of possible ways to achieve that goal using login
shell features or similar.

If someone wants to get a different editor to compose their mail in than
the one the mail reader was compiled to use (e.g. nano instead of pico
when using pine) then I'm absolutely certain there are user features to
control that too.

If someone wants to use an unfamiliar environment that might not have
the normal editor or pager or whatever functions they think should be
standard accross their universe then they should consider learning to
type them either by reference, e.g. invoke "$EDITOR", or by explict
uniqe name, e.g. invoke "vim" if you want "vim" (and demand that it be
installed on the system you're using if it's not there already :-).

Those of us who've been using disparate types of systems for decades
have carefully crafted and tuned our ~/.profile or whatever so that it
adapts to the target system and provides us with all the
touchy-feely-friendly aspects of home that we like to have.  (Some of us
go overboard with that, but that's our perogative, right!  :-)

If that's not already enough ways to make this work for people then
pkg_alternatives certainly is not the right way either.

pkg_alternatives should die as quickly and as painlessly and as
completely as possible.  To put this bluntly it was a very bad idea from
the start and it doesn't deserve any "fixing" because it simply cannot
be fixed -- the very concept is wrong.  This now-recurring thread of how
to make it work is simply additional proof of its inherent flaws.

If anyone really wants to provide some mechanism for "packaging"
"standardized" command names for alternative commands (e.g. for
supporting pkgsrc on those poor desolate systems which might not have
one's favorite NetBSD features, including those built using pkgsrc for
their entire userland from scratch) then the only right way to do that
is with a meta package that just installs a symlink or a tiny,
configurable, wrapper script (and perhaps depends on the target file's
package(s)) to (default to) a name chosen at compile time.  That means
making sure that all packages that might provide commands which have the
same functionality must install all their files with unique names so
that any/all such packages can be simultaneously installed, but that
should be a good goal to shoot for regardless.

I.e. "editors/nvi" should only install a command called "nvi", and
"editors/vim" should only install a command called "vim", etc., and
maybe some "alt/vi" package could install a script that invoked
"$EDITOR" and the users could "export EDITOR=vim" or "export EDITOR=nvi"
to make their choice with a system-wide runtime default set in
/etc/profile or wherever, and a final last-ditch default chosen by the
builder:

	#! /bin/sh
	exec ${EDITOR:=@PKG_DEF_EDITOR@} $@

K.I.S.S.  Please.  Get this "pkg_alternatives" thing right out of
pkgsrc.  It simply does not belong there, even if it is just optional.
It is too much additional unnecessary complexity in an already very
complex system and it's going to be _way_ too confusing for users.  We
already have far too many of this type of wheel invented and deployed
and we don't need yet one more incompatible variant that's unique to one
particular type of system.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>