Re: "doc" option

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Nov 28, 2010 at 06:11:34PM +0300, Aleksej Saushev wrote:
> 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.
> 
> I don't see how it makes packages harder to maintain,
> some options are supported better than others already,
> and nobody seems to have problems with that.

It's impossible to tell which of the options get used, how often, and
by whom.  That makes it a bit difficult to tell if people have
problems with that.
 
> It is the lack of this option that causes headache to those who have needs
> to install packages without documentation a nightmare, one has to maintain
> personal copy of all interesting packages or consider non-pkgsrc ways to
> maintain software installation.
> 
> I think that we can advertise "doc" option as experimental for some time,
> if that matters. This is a kind of improvement, and we may expect that users
> understand experimental status.

I'd really like to see the evaluation of some other approaches before
any changes are made.  dillo talked about sub-packages in the past.  I
haven't ever seen a design document, but I'm sure there's one flying
about.  In pkgsrc, we've also split into separate packages in the past
to avoid circular dependencies, which Greg notes was a net loss,
although I'd be more interested in seeing why, as it's the way Debian
packages operate usually (they used to have 27 separate packages for
boost). I've been mulling over the idea of filtering binary packages
at package install time, along with modification of PLISTs. I'm not
sure how effective this would be, but it would be the least intrusive
on the build side.

It depends where we want to take the hit.

Regards,
Alistair