Re: zlib options

[Adrian Portelli <adrianp%stindustries.net@localhost>]

Taylor R Campbell wrote:
> Last month I submitted a PR, now fixed thanks to Jeremy Reed, for
> enabling zlib support in OpenSSL.  I looked a little further, and
> found a number of packages that have zlib-related options.  There is
> no option named `zlib' in mk/defaults/options.description; there are
> options `bzip2', `gzip', and `lzw'; and lang/clisp and net/rbldnsd
> also have a `zlib' option.  There is also a `links-zlib' option used
> only by www/links, and there are three options `unrealircd-ziplinks',
> `inspircd-ziplinks', and `ziplinks' used by different IRC server
> packages that enable zlib.  Finally, www/lighttpd has a `bzip' option
> that enables support for bzip2, which is misleading.
> 
> I don't know the conventions governing the naming of these options,
> and whether they suggest distinguishing `support for a library X'
> (e.g., zlib) from `support for functionality that happens to depend on
> a library X' (e.g., ziplinks), but this collection of options seems
> somewhat inconsistent, and if nothing else it would be nice for the
> `zlib' option to be documented.

I can understand where you're coming from there and the general rule of
thumb that I've followed is if you're implementing something that's just
for _a_ package then specify it as such e.g. ${PKGNAME}-foo.  The idea
is that if in the future more than one package needs it you go and
rename it to just 'foo'.  The options.mk framework has the functionality
to deal with this.  Of course this relies on you recognising that you've
done this and doing the actual work.  Clearly in the case of the
ziplinks options I'm guilty here of not doing this as I'm probably
responsible for more than one of those :)

In terms of the description as 'functionality' -vs- 'library' I think
it's really a mix at the moment.

adrian.

BTW: I've added a description for zlib