On Tue, May 10, 2005, Thomas Lotterer wrote: > On Tue, May 10, 2005, Matthias Kurz wrote: >> On Tue, May 10, 2005, Michael Schloh wrote: >>> %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. [...] > Then there are three choices:
#1 Supply each package containing docs with a 'with_docs' option
#2 Supply only packages with new dependencies with a 'with_docs' option
- Others install docs or not dependending on --includedocs as usual
#3 Never supply a 'with_docs' option, only installing docs when no
dependency problems arise (due to generation for example)
Currently we do not adhere to any of the three. I prefer #1 or #3, because
they lead to less confusion. #2 sometimes installs docs even when no
'with_docs' is present, and sometimes doesn't even when 'with_docs yes'.
>>> 2. Do we package absolutely all vendor docs even when they overlap?
>>>
> Once we start I recommend putting in everything we can grab. Sometimes
> even 3rd party docs like HOWTOs etc.
>
And if it gets too sloppy (diverging structures) or heavy (storage)?
>>> 3. Where do the docs go?
>>>
> Or maybe a new "toplevel" dir using %{l_prefix}/doc/<package>/<here>
>
Your idea is already in the OpenPKG sources. From rpmmacros:
%l_docdir %{l_prefix}/doc
>>> Where do we document and enforce this new standard?
>>>
> The speclint enforcement has been proven to work very well, also it is
> incomplete because of a missing human readable "standards" document.
>
So I suppose your opinion is that we first need a human specification, and
then logically build it into the spec linter? Does Martin agree?
--
Michael Schloh von Bennewitz <[EMAIL PROTECTED]>
Development Team, Operations Northern Europe
Cable & Wireless Telecommunications Services
Tel +49-89-92699-227, Fax +49-89-92699-808
pgpNy7w5Ais5E.pgp
Description: PGP signature
