tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "doc" option

On Sun, Nov 28, 2010 at 11:46 PM, Aleksej Saushev <> 
> Joerg Sonnenberger <> writes:
>> On Mon, Nov 29, 2010 at 01:17:19AM +0300, Aleksej Saushev wrote:
>>> Joerg Sonnenberger <> 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 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 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

Home | Main Index | Thread Index | Old Index