On Tue, Jul 25, 2006 at 04:32:58PM +0200, Matthias Saou wrote:
Ralf Corsepius wrote :
> If %{_datadir}/<something>/COPYING is used by a package, it's data, not
> documentation. %doc'ing it would be a fault.
Why? I don't understand why you claim (and not even just suggest) that.
%_defaultdocdir even defaults to a sub-directory of %_datadir in our
current setup.
For minimal chroots you can install packages w/o docs, therefore the
functionality of the package should not be hindered if docs are
missing. Man & info, as well as /usr/share/doc/* are usually
discardable, e.g. only used directly, not though the application.
I don't see why a program's data under %_datadir couldn't
contain
its own online documentation, accessible from the program
itself. And I really think this should be considered perfectly fine,
as long as all of the relevant files are tagged as %doc in order to
be easily identifiable when querying the package.
This is even probably the reason why the %doc tag exists, since
otherwise, why would you need to query a package for its
documentation if it was mandatory for all of it to be under
/usr/share/doc/name-version-rel?
It seems like the only rpm-internal purpose of the doc flag on files
is indeed to be able to skip them on installation, but this knowledge
has been burried in the sands of time. As a side effect %doc on
relative paths performs a copy operation, too, which is the most
common use today.
I think it's better to not assume %doc'ed files are really around for
the application to use.
BTW are gnome help files tagged as %doc?
--
Axel.Thimm at
ATrpms.net