Re: "doc" option

[Aleksej Saushev <asau%inbox.ru@localhost>]

Greg Troxel <gdt%ir.bbn.com@localhost> writes:

> David Brownlee <abs%absd.org@localhost> writes:
>
>> There seem to be two different issues in this thread. I think we
>> should consider them separately. Also there may be some options under
>> each which have not been considered:
>> a) Eliminating docs on systems with limited storage
>> b) Avoiding the cost of building building depends such as tex &
>> doxygen to generate docs for some packages
>
> nice summary and agreed that these are separate issues
>
>> 'a)' really feels like it should have an option patch to pkg_tools to
>> exclude certain dirs on package generation or install. I would
>> personally prefer install as it keeps the binary packages the same,
>> though I could understand some would prefer otherwise.
>
> That sounds like a good solution.  Aleksej - would that address your use
> case?

Yes, this would address my use case. The problem I see with it, is that
one has to modify packages to obey more strict rules (like installing
documentation into share/doc) or marking documentation files with
special tag.

Plus, it requires tinkering at pkg_install, and you know arising
communication problems with Joerg.

It is hard to estimate if "doc" option is more or less invasive than
this way, but it is easier to get started with.

>> For 'b)' all of the options incur additional maintenance:
>> 1) Split the package into a foo & foo-doc, built & generated at the
>> same time. Very nice for binary users, doesn't help the main issue
>> here for source.
>
> True, and binary users could use method (a) if they don't want the docs,
> and "build time pain" consideration doesn't apply to them.
>
>> 2) Split the package into a foo & foo-doc, built as separate packages.
>> Helps both binary & source. For certain packages it may end up being
>> simplest to just build everything for both packages but only include
>> docs & non docs in PLIST
>
> If you don't refrain from doc building for the non-doc package, I don't
> think we get the benefit.
>
>> 3) Add 'doc' option to packages. Makes updates a little more fiddly
>> and adds more binary package variants.
>
> This could also be temporary until something better comes along.
>
>> 4) Add a special pass when updating the package to build the docs &
>> then tar & bzip them and put on ftp.netbsd.org. The checked in source
>> build then pulls down the pre-generated docs & includes. Slightly more
>> work on update but relatively simple automatable work (providing the
>> package provides a 'build without docs' option). Could even be
>> combined with '2)'.
>
> An intriguing thought, but I wonder how hard that will really be by the
> time it's fully satisfactory.  It feels like half-binary packages, or
> some sort of distributed version of ccache for tex, or ?

5) Create multiple binary packages at package creation time.

This generalises to all half-modular packages like Erlang,
but still may require modification of pkg_tools.


-- 
HE CE3OH...