On Tue, 22 Apr 2008, Travis Willard wrote:

On Tue, Apr 22, 2008 at 1:05 PM, Aaron Griffin wrote:

...

I'm really really sick of people making mountains out of the docs molehill... it's such a petty issue...

Would anyone honestly care if we removed the !docs option from makepkg.conf by default, and let each maintainer add options=(!docs) if the docs are too big for a given package?

No need to do the rebuilds all in one go, just let the docs trickle in...

Opinions anyone?

I was about to suggest the same thing.

I also share the same feeling so +1 from me. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Tue, Apr 22, 2008 at 12:31 PM, Dan McGee wrote:

On Tue, Apr 22, 2008 at 12:15 PM, Travis Willard wrote:

...

On Tue, Apr 22, 2008 at 1:05 PM, Aaron Griffin wrote:

...

I'm really really sick of people making mountains out of the docs molehill... it's such a petty issue...

Would anyone honestly care if we removed the !docs option from makepkg.conf by default, and let each maintainer add options=(!docs) if the docs are too big for a given package?

No need to do the rebuilds all in one go, just let the docs trickle in...

Opinions anyone?

I was about to suggest the same thing.

Arch prefers manpages, there is no doubt there. We also prefer vanilla packages, which could very well include packaging and installing upstream documentation as the authors intended. I'm fine with keeping docs around.

Yeah, let me be fully clear here. The first email comes off as though I am saying "People are complaining, let us fix it". That is close to the truth but not exactly it. The doc thing always sat oddly with me. We prefer vanilla packages, but we remove some crap FROM these vanilla packages. That seems counter-intuitive to me. Vanilla packages are vanilla, not modified to suit some internal opinions. If we want to provide the fullest "framework" of a distro, we shouldn't rampantly remove stuff that some people may find useful in a base system

eliott wrote:

On 4/22/08, Aaron Griffin wrote:

...

On Tue, Apr 22, 2008 at 12:31 PM, Dan McGee wrote:

...

On Tue, Apr 22, 2008 at 12:15 PM, Travis Willard wrote:

...

On Tue, Apr 22, 2008 at 1:05 PM, Aaron Griffin wrote:

...

I'm really really sick of people making mountains out of the docs molehill... it's such a petty issue...

Would anyone honestly care if we removed the !docs option from makepkg.conf by default, and let each maintainer add options=(!docs) if the docs are too big for a given package?

No need to do the rebuilds all in one go, just let the docs trickle in...

Opinions anyone?

I was about to suggest the same thing.

Arch prefers manpages, there is no doubt there. We also prefer vanilla packages, which could very well include packaging and installing upstream documentation as the authors intended. I'm fine with keeping docs around.

Yeah, let me be fully clear here. The first email comes off as though I am saying "People are complaining, let us fix it". That is close to the truth but not exactly it.

The doc thing always sat oddly with me. We prefer vanilla packages, but we remove some crap FROM these vanilla packages. That seems counter-intuitive to me. Vanilla packages are vanilla, not modified to suit some internal opinions. If we want to provide the fullest "framework" of a distro, we shouldn't rampantly remove stuff that some people may find useful in a base system

I was certainly resistant to the idea at first, as your original email did sound like 'I am doing it because I got tired of hearing people complain'. That isn't a good reason to me, as there will always be people complaining about something.

However, since you provided a sound technical reason, and clarified your position (thanks for that by the way), I have no problem with it.

I agree with the position. I like vanilla == upstream. - P

On Tue, Apr 22, 2008 at 4:52 PM, Jan de Groot wrote:

On Tue, 2008-04-22 at 12:05 -0500, Aaron Griffin wrote:

...

I'm really really sick of people making mountains out of the docs molehill... it's such a petty issue...

Would anyone honestly care if we removed the !docs option from makepkg.conf by default, and let each maintainer add options=(!docs) if the docs are too big for a given package?

No need to do the rebuilds all in one go, just let the docs trickle in...

Opinions anyone?

What do we do with gtk-doc documentation? They're very useful when developing software, but they take a shitload of space compared to the libraries and include files shipped with a library like glib2. Before we stripped these docs, glib2 would take >50MB, now with stripped docs, it's 8-9MB in size. I always defended the removal of gtk-doc API documentation as "we don't ship docs by policy". If we change this policy, I have no serious defense against keeping these docs any longer, which means gtk-doc API documentation will get included, meaning a base package like glib2 will grow to 50MB again. Another option is to build them in standalone packages like we have with qt3-doc for example. AFAIK the latest versions of gtk-doc have makefile targets to build standalone documentation, but this means increase in workload and loss of KISS as we're splitting packages again.

Actually, this is the case where I was talking about leaving it up to the maintainers - you'd have to add options=(!docs) to those gtk-doc packages to kill those off, assuming that's acceptable.

On Tue, Apr 22, 2008 at 5:06 PM, Dan McGee wrote:

On Tue, Apr 22, 2008 at 4:52 PM, Jan de Groot wrote:

...

...

On Tue, 2008-04-22 at 12:05 -0500, Aaron Griffin wrote:

...

I'm really really sick of people making mountains out of the docs molehill... it's such a petty issue...

Would anyone honestly care if we removed the !docs option from makepkg.conf by default, and let each maintainer add options=(!docs) if the docs are too big for a given package?

No need to do the rebuilds all in one go, just let the docs trickle in...

Opinions anyone?

What do we do with gtk-doc documentation? They're very useful when developing software, but they take a shitload of space compared to the libraries and include files shipped with a library like glib2. Before we stripped these docs, glib2 would take >50MB, now with stripped docs, it's 8-9MB in size. I always defended the removal of gtk-doc API documentation as "we don't ship docs by policy". If we change this policy, I have no serious defense against keeping these docs any longer, which means gtk-doc API documentation will get included, meaning a base package like glib2 will grow to 50MB again. Another option is to build them in standalone packages like we have with qt3-doc for example. AFAIK the latest versions of gtk-doc have makefile targets to build standalone documentation, but this means increase in workload and loss of KISS as we're splitting packages again.

This is one of those where you can still say "Enough is enough, I don't want a 500% increase in package size when I include the docs, so I'm not going to." Surely someone is willing to maintain a docs package in community? (That is if you do not want to maintain one in extra).

It is a lot harder to justify a 10K space savings for other packages, but 40MB is a different story.

Here's another option - we could remove the info dirs from the DOC_DIRs setting in makepkg.conf, leaving only the gtk-doc dirs. Either that or the way I suggested above (gtk-doc packages just add !docs to the package options). What do you guys think?

On Wed, Apr 23, 2008 at 10:30 AM, Travis Willard wrote:

On Wed, Apr 23, 2008 at 11:28 AM, Aaron Griffin wrote:

...

On Tue, Apr 22, 2008 at 5:06 PM, Dan McGee wrote:

...

On Tue, Apr 22, 2008 at 4:52 PM, Jan de Groot wrote:

...

...

On Tue, 2008-04-22 at 12:05 -0500, Aaron Griffin wrote:

...

I'm really really sick of people making mountains out of the docs molehill... it's such a petty issue...

Would anyone honestly care if we removed the !docs option from makepkg.conf by default, and let each maintainer add options=(!docs) if the docs are too big for a given package?

No need to do the rebuilds all in one go, just let the docs trickle in...

Opinions anyone?

What do we do with gtk-doc documentation? They're very useful when developing software, but they take a shitload of space compared to the libraries and include files shipped with a library like glib2. Before we stripped these docs, glib2 would take >50MB, now with stripped docs, it's 8-9MB in size. I always defended the removal of gtk-doc API documentation as "we don't ship docs by policy". If we change this policy, I have no serious defense against keeping these docs any longer, which means gtk-doc API documentation will get included, meaning a base package like glib2 will grow to 50MB again. Another option is to build them in standalone packages like we have with qt3-doc for example. AFAIK the latest versions of gtk-doc have makefile targets to build standalone documentation, but this means increase in workload and loss of KISS as we're splitting packages again.

This is one of those where you can still say "Enough is enough, I don't want a 500% increase in package size when I include the docs, so I'm not going to." Surely someone is willing to maintain a docs package in community? (That is if you do not want to maintain one in extra).

It is a lot harder to justify a 10K space savings for other packages, but 40MB is a different story.

Here's another option - we could remove the info dirs from the DOC_DIRs setting in makepkg.conf, leaving only the gtk-doc dirs. Either that or the way I suggested above (gtk-doc packages just add !docs to the package options).

What do you guys think?

I think we should remove doc-stripping on a global basis, and those packages that still want to strip their docs should explicitly say so. Seems the most 'vanilla' solution to me.

makepkg really shouldn't be tailored to Arch, I've tried to get away from that. I'd like to put sane defaults there (don't strip docs, but define DOC_DIRS as all relevant doc directories), and let either the PKGBUILD of pacman or the individual developers make any further customizations. -Dan

On 4/24/08, Aaron Griffin wrote:

On Tue, Apr 22, 2008 at 4:52 PM, Jan de Groot wrote:

...

What do we do with gtk-doc documentation? They're very useful when developing software, but they take a shitload of space compared to the libraries and include files shipped with a library like glib2. Before we stripped these docs, glib2 would take >50MB, now with stripped docs, it's 8-9MB in size. I always defended the removal of gtk-doc API documentation as "we don't ship docs by policy". If we change this policy, I have no serious defense against keeping these docs any longer, which means gtk-doc API documentation will get included, meaning a base package like glib2 will grow to 50MB again.

Hey Jan, I just want to make sure you're ok with this, because you're the hardest hit. I am thinking that stripping gtk-docs and things of that nature is perfectly acceptable. I would defend it with "they're too big and it's my freaking package". Let me know if you have any qualms here.

Keep in mind, I'm really thinking of JUST info pages here - there are a lot of GNU tools that document all their stuff in info pages - I'm not too concerned about HTML documentation that's pretty much only usable in a desktop-environment (read: you can just browse it online)

Maybe something like.. including info pages in 'core' packages only, as some info pages for core utils might be required to get a box online or up and running (like grub for instance). I honestly don't know what people request info pages for with regularity... But making a policy distinction such as 'core packages only' would provide clarity to end users (they wouldn't have to guess what has info and what doesnt), as well as make it easier for packages to just get their work done.