Subject: Re: CVS commit: pkgsrc/databases
To: None <cube@cubidou.net>
From: Michal Pasternak <michal@pasternak.w.lub.pl>
List: tech-pkg
Date: 04/20/2004 19:31:39
cube@cubidou.net [Tue, Apr 20, 2004 at 07:01:42PM +0200]:
> On Tue, Apr 20, 2004 at 06:51:10PM +0200, Michal Pasternak wrote:
> [...]
> > And, I've still haven't seen a single good pro-doc/html argument. Sorry!
>
> You're not the one that will have to go through all the packages,
> correct them, and then do the commits.
I am not just being a noisy person, if I am ranting a lot about some topics,
this also means I am ready to do that job and I know, what does it take.
Last month I've e-mailed a few pkgsrc developers, that I can do more pkgsrc
work, but I need closer cooperation with the project. Perhaps if some
commiter would want to review & commit my patches for doc/html -> doc/
transition, I could do all the work.
> Besides, there might be good reasons to at least keep vi-unfriendly doc
> away, like auto-registering a package that you don't need on the final
> target. I frankly don't give a damn about html documentation on a
> server that only sees ssh logins.
You have a point here. FreeBSD Ports define a build variable called NO_DOCS,
which prevents documentation files from being installed, but I think that is
a lousy idea. Debian on the other hand almost always has "package" and
"package-docs" - docs are kept in separate packages - and this takes much
more sense.
gtk2+ comes with html docs, but it could be patched _not_ to install them;
then we could create gtk2+-docs either from html-docs tarball available on
the site, or from the same tarball as the sources are (for example,
py-twisted-docs use 2nd approach).
There are many more packages like this; in general I think, that separating
HTML docs from the rest of package is a good idea and it should be done
whenever possible. I could also do some work in this area, only that I'd
like to hear from some pkgsrc developers first, that such work is needed,
that such work has sense and it will be introduced.
--
m