On Tue, May 10, 2005, Matthias Kurz wrote:
> On Tue, May 10, 2005, Michael Schloh wrote:
>
> Yes. I thought, %docdir is just [working recursive]
>
I hope this is the way it works but it has to be verified.
> > So far, we have a few things which I hope is clear to everyone.
> > Please make corrections if any of the following is wrong:
> >
> > --includedocs (RPM feature): includes files tagged with '%doc'
> > --excludedocs (RPM feature): excludes files tagged with '%doc' (the
> > default)
> > %doc (RPM feature): describes a file as optional documentation
> > %docdir (RPM feature): describes a directory as containing documentation
> > with_doc (OpenPKG feature): inconsistent option which should be removed
> > $ openpkg rpm -qd <pkg> (qd is RPM feature): list documentation
> >
Close to how I understand it. But there is an important thing missing
here. The RPM feature controls the installation of documentation files
from the binary RPM into the filesystem. The OpenPKG feature with_docs
controls the inclusion of documentation files from the buildroot
into the binary RPM. The RPM feature is simply a "copy" or "skip"
decision. However, the OpenPKG feature sometimes means that additional
dependencies exist at build time. Consider a package that includes docs
in a single "original" format. During build the docs might be converted
into additional formats using - BANG! - additional tools which are
not part of the package. People will hate us if we insist having them
install text based web browsers just to dump a HTML page into TXT,
install tex just to render a beautiful postscript file and install some
x-to-PDF converter - just to finally skip the docs at install time
later. The need to create the docs during build is the actual problem
which prevented us to support them.
> > We might consider the questions:
> >
> > 1. How do we want to consistently use the tags '%doc' and '%docdir'?
> >
We can only decide when we have understood how $docdir really works.
> > 2. Do we package absolutely all vendor docs even when they overlap?
> > - When a user's guide is available in all .html, .ps, and .pdf,
> > then which do we prefer to package?
> >
Once we start I recommend putting in everything we can grab. Sometimes
even 3rd party docs like HOWTOs etc.
> > 3. Where do the docs go?
> > - %{l_prefix}/share/<package>/<here>?
> > - %{l_prefix}/share/<package>/doc/<here>?
> >
Or maybe a new "toplevel" dir using %{l_prefix}/doc/<package>/<here>
> > ...and of course the organisational questions:
> >
> > Where do we document and enforce this new standard?
> > - Documented in the long outdated handbook?
> > - Documented in a new 'package standards' document?
> > - Not documented anywhere, and only enforced?
> > - Enforced in the speclint script of openpkg-tools?
> >
The speclint enforcement has been prooven to work very well, also it is
incomplete because of a missing human readable "standards" document.
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [email protected]
