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                   openpkg-dev@openpkg.org

Reply via email to