Bug 993817 - libdbusmenu possibly affected by F-20 unversioned docdir change
libdbusmenu possibly affected by F-20 unversioned docdir change
Product: Fedora
Classification: Fedora
Component: libdbusmenu (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Eduardo Echeverria
Fedora Extras Quality Assurance
Depends On:
Blocks: F20UnversionedDocDirs
  Show dependency treegraph
Reported: 2013-08-06 08:21 EDT by Ville Skyttä
Modified: 2013-08-29 08:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-27 03:09:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2013-08-06 08:21:25 EDT
libdbusmenu was identified as a package possibly needing maintainer attention
due to the F-20 unversioned doc dir change. The identification is not
foolproof, it is basically this grep:

    grep -E "(/doc|_docdir|_defaultdocdir).+version" *.spec

Please review your package and make the appropriate changes, if any. A
good starting point is checking the lines output by the above grep for
your specfile. For the vast majority of packages, after the changes,
the expected outcome is that documentation dirs in /usr/share/doc
should no longer contain the package version.

More information and tips:
Comment 1 Fedora Update System 2013-08-27 03:06:52 EDT
libdbusmenu-12.10.2-5.fc19 has been submitted as an update for Fedora 19.
Comment 2 Fedora Update System 2013-08-27 03:08:04 EDT
libdbusmenu-12.10.2-5.fc18 has been submitted as an update for Fedora 18.
Comment 3 Eduardo Echeverria 2013-08-27 03:09:36 EDT
Comment 4 Ville Skyttä 2013-08-27 03:25:55 EDT
This change affects F-20+ only. Why push updates to F-18 and F-19 that change nothing? If that's correct, please cancel/delete the updates in comments 1 and 2.
Comment 5 Eduardo Echeverria 2013-08-29 05:50:19 EDT
Yes, I'm aware of it

take a look into the spec

As you can see pkgdocdir ( %{!?_pkgdocdir: %global _pkgdocdir %{_docdir}/%{name}-%{version}}), works just for the main package and not for the subpackages., in this case some documentation belong to subpackages libdbusmenu-glib-devel and libdbusmenu-tools, so I've a made a change in the spec doing a conditional between f20 and earlier in order to not have a different spec in my branches.

Best Regards
Comment 6 Ville Skyttä 2013-08-29 07:21:08 EDT
Yes, I can see. And yes, it's fine to do it that way in order to have the same specfile in different branches in git.

What's NOT fine is to actually push this F-18 and F-19 update through bodhi and to end user systems because as said, they change nothing for existing F-18 and F-19 users, it's essentially just a rebuild they need to download and install to gain nothing. Actually it's even worse than that because the changelog entry they'll see is "switch to unversioned documentation directory" which is not even true for distros earlier than F-20.

Again, please cancel/delete the updates in comment 1 and 2 (*in Bodhi*, no need to touch git).
Comment 7 Michael Schwendt 2013-08-29 08:30:05 EDT
Hmmm, I find the spec file too complicated and confusing after the change:

Apparently, some docs are installed to %{buildroot}%{_docdir}/%{name} during %install and then they are moved to other locations. Anything not moved will be included in the base package without a warning.

For example, as one side-effect of this, there's an empty "examples" dir in there already: http://koji.fedoraproject.org/koji/rpminfo?rpmID=4359185

In the future, more such accidentally/unknowingly included docs might come, because the %doc magic in the base package happily includes everyting found in %{_docdir}/%{name}.

Further, this part of the diff,

  %if 0%{?fedora} >= 20
  %global tools_doc %{_docdir}/%{name}-tools
  %global glib_doc  %{_docdir}/%{name}-glib-devel
  %global tools_doc %{_docdir}/%{name}-tools-%{version}
  %global glib_doc  %{_docdir}/%{name}-glib-devel-%{version}

is close to being macro-madness with not much benefit. Why? Because all of this is not done to share a common %{_docdir}/%{name} directory, but to create separate docdirs per subpackage. These extra dir definitions aren't needed.
The %doc magic for the -tools subpackage operates on %{_docdir}/%{name}-tools, non-versioned since F20, versioned for older dists.

It would be easier to simply use the %doc magic to distribute the installed files to their subpackages with this old-school trick:

  rm -rf __tmp_docs ; mkdir __tmp_docs
  mv %{buildroot}%{_docdir}/%{name}/examples __tmp_docs
  mv %{buildroot}%{_docdir}/%{name}/README.dbusmenu-bench __tmp_docs

  %files doc
  %doc __tmp_docs/examples/*
  %files jsonloader
  %doc __tmp_docs/README.dbusmenu-bench


You should also try whether you can call %configure with an adjusted --docdir parameter to install its docs to a custom path, which would not collide with the base package %doc magic. *Then* you would get helpful build failures for any docs you haven't moved during %install.


Some packagers will consider the following as even cleaner:

Unless you insist on keeping those separate docdirs per subpackage (three or more already), you could even keep everything in %{_docdir}/%{name} and add the extra files (README COPYING COPYING.2.1 COPYING-GPL3 AUTHORS) not via %doc magic but by copying them to their place in %install.

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