[ On Monday, April 26, 1999 at 08:41:02 (-0400), Todd Vierling wrote: ]
> Subject: Re: handling "optional" features in packages which add dependencies  on other packages
>
> On Sun, 25 Apr 1999, Greg A. Woods wrote:
> 
> : For now I've patched pgsql's configure.in not to look for ncurses or
> : sfio, and have added ".if defined(USE_READLINE)"
> 
> A better fix would be for us to add the functionality you're seeking in
> readline to libedit.  The latter is really meant to be a complete
> replacement for the former.

Hmmm... That's not likely going to work, and isn't really the point of
what I was trying to say.  GNU Readline's API is totally different from
that of NetBSD's libedit, and I don't see any good reason to merge them
either.  Mind you it might make sense to try and convince as many third
party software authors and maintainers as possible to use libedit
instead of GNU readline, though that'll require someone creating,
maintaining, and promoting a separate *portable* libedit release for
them to use on other platforms.  In the mean time we have a readline
package in pkgsrc and we can ensure there are dependencies registered
against it where appropriate -- it's just a matter of making sure we
catch all the places where this is necessary.

I.e. some third-party packages (such as pgsql and amanada) will
automatically make use of additional/optional libraries and other tools
(such as GNU readline) if they happen to exist on the build system, but
are also happy to do without these optional features too.

Unfortunately the package system often has no way to know if those
packages are using such libraries or not, and has no control over
whether the package is built with those libraries, or not (beyond either
patching the packages build system to ignore all optional libraries, or
to always require them all as dependants, or some mix of these options).
There's no feedback *or* control mechanism for the package system to
use.  The package maintainer must examine the package's build system in
detail to understand what options it might automatically use and must
patch the build system to take control over these automatic decisions so
that dependencies can be registered.

This situation is far from ideal, and once you wander away from GNU
Autoconf'ed packages it gets extremely complex too.  That's why I'm a
big proponent of GNU Autoconf (the more packages which use Autoconf, the
easier the pkgsrc/ports maintainer's jobs become), and why I'm trying to
convince the Autoconf folks that that some kind of command-line control
is necessary for the AC_CHECK_LIB macro (and any similar macros).

Lastly there's the question of who gets to make the decisions -- does
this ability sit totally with the package maintainer, or should there be
hooks to allow the users to make some of these choices too?  I think the
user should have control where possible, and that's why I'm proposing
standardising a simple and predictable naming scheme for these control
flags.

> : I.e. have a PKG_{add-on} variable that controls the default use of an
> : add-on dependant for any other package that might use it, and then have
> : PKG_{parent-pkg}_{add-on} that can override the default for a given
> : dependant in some specific package.  This gets very verbose though.
> 
> There is one that might fit this scheme better: libgettext.

Doesn't GNU gettext have a much more standard API?  I.e. isn't it a
worse example?  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>