Subject: Re: Maxi-packages
To: Berndt Josef Wulf <wulf@ping.net.au>
From: Gavan Fantom <gavan@coolfactor.org>
List: tech-pkg
Date: 02/04/2000 18:56:51
On Sat, 5 Feb 2000, Berndt Josef Wulf wrote:

> NetBSD doesn't make a distinction between "must have" packages 
> to succesfully compile/build/run an applicaton and "nice to have" 
> feature in order to make it more versatile and flexible.
> 
> Personally, I would like to see the packages system to make a package
> to depend only on those auxillary programs which are needed to compile,
> build and run an application correctly. The configuraton of "nice to have"
> features should be left to the user. In the simplest case this may be
> a list of options which are disabled by default in the packages
> Makefile, but may be enabled through user interaction.

How about providing the options MINIMAL_DEPENDS and INTERACTIVE_DEPENDS in
mk.conf. The current way of doing things would be represented by
MINIMAL_DEPENDS=NO and INTERACTIVE_DEPENDS=NO. The meaning of
MINIMAL_DEPENDS is fairly obviously not to pull in anything which is
optional (like TeX for magicfilter), and INTERACTIVE_DEPENDS would mean
that the user would be prompted for each optional package. In this case,
the default answer could be provided by the value of MINIMAL_DEPENDS.

For example:

$ cd /usr/pkgsrc/misc/mypackage
$ make
...
...
*** mypackage-1.00 can benefit from hugething-0.93
*** Install hugething-0.93? [y]
...
*** Registering installation for hugething-0.93
*** Returning to build of mypackage-0.93
*** mypackage-1.00 can benefit from smallthing-1.58
*** Install smallthing-1.85? [y] n
*** Extracting for mypackage-1.00
...

Obviously, this means you can never do a make in a script if
INTERACTIVE_DEPENDS is set, although there's always the option of
INTERACTIVE_DEPENDS=NO make.

It would also be nice to provide a way to specify on invokation which
packages to pull in, although I guess that's trivially doable from a
script anyway just by installing the optional packages before even calling
make.

The main advantage of this would then be flexibility for end users, so
that they don't have to fully understand how the package system works in
order to use it.

Also, if anyone's adventerous enough to do it, the prompt could even be
made part of a menu-based framework for installing packages, kinda like
FreeBSD does it. If you do that though, please leave a way of reverting to
good old text as I do find FreeBSD's menus rather irritating.

-- 
Gillette - the best a man can forget