Bug 999778 - %{_docdir_fmt} expands to %{NAME}
%{_docdir_fmt} expands to %{NAME}
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Florian Festi
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-22 01:53 EDT by Ralf Corsepius
Modified: 2015-06-29 08:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 08:18:09 EDT
Type: Bug
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 Ralf Corsepius 2013-08-22 01:53:37 EDT
Description of problem:

In a spec file, I am trying to use 
%{!?_docdir_fmt: %global _docdir_fmt %{name}-%{version}}
in analogy to what has been recommended for %{_pkgdocdir}

This results into the %{_docdir_fmt} being expanded into the 
string "%{NAME}" instead of the actual package name.

# rpm -qlp ....
.../doc/%{NAME}/...


Version-Release number of selected component (if applicable):
redhat-rpm-config-9.1.0-53.fc20
redhat-rpm-config-9.1.0-53.fc21

How reproducible:
Always

Actual results:
Referencing %{_docdir_fmt} in specs expands to %{NAME}

Expected results:
Referencing %{_docdir_fmt} to expand into a string (e.g. the contents of %NAME).
Comment 1 Ville Skyttä 2013-08-22 04:53:26 EDT
No, it's expected for %{_docdir_fmt} to expand to %{NAME} (%{NAME} is not a macro, it's a rpm header formatting variable!). There's quite a bit of discussion about it recently on Fedora mailing lists, for example in this thread one packager was trying to use it like you (which cannot be cleanly done), read the two links in this post for more details:
http://article.gmane.org/gmane.linux.redhat.fedora.extras.packaging/9228

I guess one could try defining it as %{name} so that it expands to something that can be used in specfiles and hope rpm's headerFormat() doesn't do anything nasty with it and also hope that it'll result in the expected behavior as it does now, but I don't intend to have a look at it. NOTABUG as far as I'm concerned, I suggest sticking with special %doc and %{_pkgdocdir}.
Comment 2 Ralf Corsepius 2013-08-22 05:24:25 EDT
(In reply to Ville Skyttä from comment #1)
> No, it's expected for %{_docdir_fmt} to expand to %{NAME} (%{NAME} is not a
> macro, it's a rpm header formatting variable!). There's quite a bit of
> discussion about it recently on Fedora mailing lists, for example in this
> thread one packager was trying to use it like you (which cannot be cleanly
> done), read the two links in this post for more details:
> http://article.gmane.org/gmane.linux.redhat.fedora.extras.packaging/9228
OK.

Then, why is %{_docdir_fmt} exposed to the user? Shouldn't it better be defined inside of rpm itself (I checked rpm's source code and am seeing the spot it is used)? 

The way it currently is implemented, it appears to be function-free macro space pollution on the packager side.

> I guess one could try defining it as %{name} so that it expands to something
> that can be used in specfiles and hope rpm's headerFormat() doesn't do
> anything nasty with it and also hope that it'll result in the expected
> behavior as it does now, but I don't intend to have a look at it. NOTABUG as
> far as I'm concerned, I suggest sticking with special %doc and %{_pkgdocdir}.

Well, I can't say to like this. There are exotic use cases where %{_pkgdocdir} alone is rather dissatifisfactory and a relative docsubdir would be desired.

Putting aside, most of these use cases are arguable/questionable, as things currently are, one either has to resort $(basename %{_pkgdocdir}) or to redesign code to cope with absolute directories.
Comment 3 Ville Skyttä 2013-08-22 08:19:17 EDT
(In reply to Ralf Corsepius from comment #2)
> Then, why is %{_docdir_fmt} exposed to the user?

My understanding is that rpm's configuration is done through macros, and macros have global visibility. Just because it is visible doesn't mean it should be used in specfiles -- in addition to _docdir_fmt there's a lot of things that fall into the same category (_rpmconfigdir, _builddir, _dbpath, _keyringpath, _rpmfilename, etc etc to name a few).

But yes, I think the _docdir_fmt mechanism is quite obscure and not optimal. But it exists.

> one either has to resort $(basename %{_pkgdocdir}) or to
> redesign code to cope with absolute directories.

Note that there's always the option to do just what was done before this change: hardcode the package's doc dir or assumption of its value. _pkgdocdir is a new convenience addition which in many cases relieves the packager from having to hardcode it, and one that didn't exist before.

I'll also parrot my opinion here that in a lot of cases (but certainly not all), it would be better for subpackages to ship their docs in the main package's docdir instead of having one of their own. _pkgdocdir happens to help nicely there.
Comment 4 Ralf Corsepius 2013-08-22 10:46:57 EDT
(In reply to Ville Skyttä from comment #3)
> (In reply to Ralf Corsepius from comment #2)
> > Then, why is %{_docdir_fmt} exposed to the user?
> 
> My understanding is that rpm's configuration is done through macros, and
> macros have global visibility. Just because it is visible doesn't mean it
> should be used in specfiles -- in addition to _docdir_fmt there's a lot of
> things that fall into the same category (_rpmconfigdir, _builddir, _dbpath,
> _keyringpath, _rpmfilename, etc etc to name a few).
> 
> But yes, I think the _docdir_fmt mechanism is quite obscure and not optimal.
> But it exists.
Sure, but ... it s***s ;)

> > one either has to resort $(basename %{_pkgdocdir}) or to
> > redesign code to cope with absolute directories.
> 
> Note that there's always the option to do just what was done before this
> change: hardcode the package's doc dir or assumption of its value.
> _pkgdocdir is a new convenience addition which in many cases relieves the
> packager from having to hardcode it, and one that didn't exist before.
The problem now actually is the opposite: Tweaking hard-coded "name-version" docdirs into "name".

> I'll also parrot my opinion here that in a lot of cases (but certainly not
> all), it would be better for subpackages to ship their docs in the main
> package's docdir instead of having one of their own.
ACK.

> _pkgdocdir happens to help nicely there.
How? I don't share this experience. It mostly doesn't change anything at all, but breaking hardcoded /usr/share/doc/<name>-<version> in specs and packages.
We have /usr/share/doc/<pkg>-doc, /usr/share/doc/<pkg>-devel, /usr/share/<pkg>/doc etc. even /usr/share/doc/<pkg>-dev (hard-coded debian docdir) somewhere ;)
Comment 5 Fedora Admin XMLRPC Client 2014-11-14 02:24:56 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Fedora End Of Life 2015-05-29 05:20:30 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 7 Fedora End Of Life 2015-06-29 08:18:09 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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