Re: "doc" option

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

Alistair Crooks <agc%pkgsrc.org@localhost> writes:

> 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.

Then we should adjust out reporting tools. With new wave of "micros"
we have to reduce storage usage or retreat.

>> 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.

We're waiting for too long without anything changing.
Is there anyone working on those alternative approaches?


-- 
HE CE3OH...