Subject: Re: pkg_alternatives as a dependency, again
To: NetBSD Packages Technical Discussion List <email@example.com>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
Date: 02/12/2005 10:46:31
On Fri, 2005-02-11 at 03:00 -0500, Greg A. Woods wrote:
> [ 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 have a system-wide 'java' command that just works,
even when there is a single vm available, what? This was impossible to
do in pkgsrc, aside from the ugly and too-specific java-wrapper package.
> 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
... which is NOT binary friendly ...
> 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.
and we are back at alternatives. If you are going to have tens of
packages providing wrappers, you can merge them all in one (i.e.,
pkg_alternatives), which has a common interface among all of them.
Julio M. Merino Vidal <email@example.com>
The NetBSD Project - http://www.NetBSD.org/