Re: "doc" option

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

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

> Julio Merino <jmmv%NetBSD.org@localhost> writes:
>
>> On 11/26/10 6:07 PM, 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.
>>
>> What's the reason for this?  Adding this as an option will only make
>> packages a nightmare to maintain.  And this option will make binary
>> packages obscure because one won't be able to tell whether the binary
>> package includes documentation or not.
>>
>> I understand the willingness to have this for some packages (where the
>> documentation is either huge or license-incompatible with the code),
>> but in these cases the documentation should be a separate package and
>> not an option.  Making this a general option is potentially harmful
>> for our users and for the maintainers.
>
> That's a good point, and I admit that I was thinking of the cases where
> building documentation is painful.  So I'd like to revise and extend my
> remarks :-)
>
> I agreee that split packages for docs are nice, but from my experience
> maintaining split packages (and in the case of gutenprint, giving up),
> doing that when upstream doesn't accomodate splitting is a lot of work.
> I certainly won't object if someone does that, of course.  So one can
> view doc options as a workaround until the glorious day when all
> packages are split like they should be.
>
> I think it makes sense to have some option to be able to avoid a package
> needlessly depending on huge toolsets, for some values of needlessly and
> huge.  Typically it's TeX and docbook-xml that are large; I don't object
> to those in theory, but on a minimal system dragging them in is
> unreasonable.
>
> I'm unclear on the benefit of removing man pages and other things that
> are small and don't cause tool bloat, but I can understand that some
> people want that.

See below.

> So perhaps in a maximally complex world there would be options
>   doc         all documentation that is inexpensive to build
>   doc-tex     all documentation that requires tex to build
>   doc-xml     all documentation that requires xml to build
> but this seems excessive at first glance.

I think that this is excessive.

> Aleksej: could you give a few examples of what you want to do and why?
> And perhaps an example diff to one package?  I think the key question is
> whether what you want is wanted by others, and cost of the change to
> those who don't want this.

My rough estimation that on pretty bare system (using spartan evilwm
environment) only pre-built and plain text documentation with manual
pages takes around 400M of file system space. On MID devices where you
have no such luxury of accessing gigabytes of storage for user data
this is too high space waste. Given that storage use for OSS software is
generally higher than that for NT world, I estimate that using pkgsrc
is too inconvenient for those space-constrained systems. I'd like to
reverse that or to reduce that at least. Read, this is something like
my personal "Desktop NetBSD" project.

I know that some other developers (and users) expressed their desire to get
rid of built and installed documentation as well. In my opinion, having
this option is at least acceptable workaround until there're better
implementations arrive. Perhaps they won't arrive at all, are we going
to wait forever?


-- 
HE CE3OH...