Bug 7077 - %doc uses %{_defaultdocdir} instead of a corresponding local spec file variable
Summary: %doc uses %{_defaultdocdir} instead of a corresponding local spec file variable
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-17 15:15 UTC by mp
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description mp 1999-11-17 15:15:00 UTC
%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 16:13:29 UTC
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.