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? > 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 ?
Attachment:
pgpyf0drpvG6E.pgp
Description: PGP signature