Re: "doc" option

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Sun, Nov 28, 2010 at 11:46 PM, Aleksej Saushev <asau%inbox.ru@localhost> 
wrote:
> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:
>
>> On Mon, Nov 29, 2010 at 01:17:19AM +0300, Aleksej Saushev wrote:
>>> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:
>>>
>>> > On Sat, Nov 27, 2010 at 02:07:16AM +0300, Aleksej Saushev wrote:
>>> >> Unless anyone objects in a week, I'll start adding "doc" option to 
>>> >> packages
>>> >> I'm interested to be stripped of installed documentation. First positions
>>> >> in the queue are occupied by modular X.org packages. I'm not going to 
>>> >> change
>>> >> current state, default will be to install documentation.
>>> >
>>> > Please do NOT randomly strip off documentation. The *only* case where
>>> > such an option should be added to an X.org package is if it requires
>>> > additional (non-trivial) dependencies. Do not make the tree harder to
>>> > maintain than necessary.
>>>
>>> Do you consider groff a trivial dependency? I don't.
>>
>> Yes. More importantly, you don't need it to create the man pages.
>
> You need it to view them. Alternative is creating catpages, which are larger
> and still as useless.

But groff does not need to be a dependency of the package.

>>> I don't see why anyone wants to use man pages on mobile device either,
>>> all of them add perceptible dead weight nevertheless.
>>
>> That argument doesn't really cut either. Man pages and other forms of
>> documentation tend to be a lot larger than other crap like static
>> libraries. Seriously, if you want to build an image for a space
>> constrained system, take a package and prune the file list by sed/awk/...
>
> How does that help? Does pkg_add support filtering files out?
> Are you going to add this functionality any time soon?

You could do a pretty simple hack by removing the files from the
destdir prior the "package" step happens.

>>> There's not a big problem to maintain package with few options.
>>
>> Yes, it is a major PITA.
>
> I maintain several packages with a number of options and don't see the 
> problem,
> what exactly is it?

Maintaining PLISTs in chunks or PLISTs with ${var} expansions to
specify what gets included or not is a royal PITA, yes.

Separate packages require more initial effort to create but: are
completely binary friendly and, in the long term, are easier to
maintain (aka one single PLIST per package!).

-- 
Julio Merino