Bug 7077 - %doc uses %{_defaultdocdir} instead of a corresponding local spec file variable
%doc uses %{_defaultdocdir} instead of a corresponding local spec file variable
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-17 10:15 EST by mp
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-11-17 10:15:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mp 1999-11-17 10:15:00 EST
%doc uses RPM_DOC_DIR, which itself is set to $RPM_BUILD_DIR/%{_docdir}
with %{_docdir} being set to %{_defaultdocdir}.
Now, %{_defaultdocdir} is a setting, which reflects the [possibly
relocated] situation on the building system.

It should instead use something, which is based on the local %{prefix}
variable of the spec file actually processed.

I would propose declaring an additional local spec file variable named
%{docdir} [without leading ``_''], which is initialized by the same
algorithm as %{_docdir}, but as a function of %{prefix} and not as a
function of %{_prefix} [, which %{_defaultdocdir} normally is].

A temporary workaround, for the time till being fixed in rpm itself,
is to put a line

  %define _docdir %{prefix}/doc

into the spec files.


May be, it would be wise to take the opportunity and look for some other
variables, which are also conceptionally to be well distinguished from
their underscored counterparts.
Comment 1 Jeff Johnson 2001-01-08 11:13:29 EST
No, %_prefix is the path, while %prefix is the side effect macro from
	Prefix: /usr
and the two have different meanings and uses. While I agree the distinction is
confusing to packagers, there's simply no way to undo the legacy without
creating Yet More Confusion.

Note You need to log in before you can comment on or make changes to this bug.