Martin J. Laubach wrote
>   Something completely different -- I have noticed that more
> and more packages include everything and the kitchen sink, which
> makes them difficult to use in normal situations. For example,
> webalizer (a httpd log analyzing tool, usually run on the web
> server), depends on png (ok), on freetype (huh?) which depends
> on gettext, and on xpm which depends on X11.
> 
>   So that package is not buildable/useable on systems without
> X11, which is what web servers often are. Isn't all that "let's
> turn on all the options and depend on everything in sight" going
> a bit overboard?


You hit a tune on my pet subject....

There are quite a number of packages which are unnecessarely
bloated by auxillary packages. I would prefer a system which calls
dependencies whenever they are needed to compile and build a
package correctly, but use an additional mechanism to allow
users to select additional options and features.

Let me take an examples - magicfilter-1.2

Its been a great companion for a long time now and has made
the installation of a wide variaty of printers a breeze. 

When magicfilter is installed as an external package, the
configure script will search the system for auxillary
utilities and determines what can be supported in the
printer filter files. Utilities which are supported but not
ound on the sytem will be ignored and hence are not be supported
which is ok in most cases. No intervention required.

NetBSD's packages system takes another approach. Here a user will
have no choice of what is supported and in its extreme
requires TeX which arguebly wouldn't be used by many users,
bloating an otherwise lean utility into a tens of megabyte
application.

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.

This can be done by creating a new file which contains the optional
features of a package, e.g. Makefile.extra. Here a user has a choice
on any additional features which can be either enabled or disable.

In case of magicfilter, I've simply deleted the dependency TeX and
happily use it ever since.

cheerio Berndt
-- 
Name    : Berndt Josef Wulf            | +++ With BSD on Packet Radio +++
E-Mail  : wulf@ping.net.au             |    tfkiss, tnt, dpbox, wampes
ICQ     : 18196098                     |  VK5ABN, Nairne, South Australia 
URL     : http://www.ping.net.au/~wulf | MBOX : vk5abn@vk5abn.#lmr.#sa.au.oc
Sysinfo : DEC AXPpci33+, NetBSD-1.4    | BBS  : vk5abn.#lmr.#sa.aus.oc