Macro usage for Fedora 20 documentation tree change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello list,

I have a package "mup" that currently fails to build in Rawhide due to the introduction of the following Fedora 20 feature:

    http://fedoraproject.org/wiki/Changes/UnversionedDocdirs

My current (broken) spec file has things like the following to fix up file paths referenced by the upstream makefile:

sed -i -e 's|DOCDIR = $(PREFIX)/share/doc/packages/mup|DOCDIR = $(PREFIX)/share/doc/%{name}-%{version}|' makefile

It's broken because the "make install" invocation installs things to "/usr/share/doc/mup-6.1" but RPM in rawhide is now looking for documentation files in "/usr/share/doc/mup" (unversioned).

My initial thinking was to set %{_docdir_fmt} if it's not already set, using:

    # Set %_docdir_fmt if it's not already defined
    %{!?_docdir_fmt: %global _docdir_fmt %%{name}-%%{version} }

And then replace the sed line above with:

sed -i -e 's|DOCDIR = $(PREFIX)/share/doc/packages/mup|DOCDIR = $(PREFIX)/share/doc/%{_docdir_fmt}|' makefile

This change allows builds to work on EPEL6, but breaks on rawhide because in Fedora 20, %{_docdir_fmt} is set to "%{NAME}". The %{NAME} macro doesn't appear to change to "mup" (my package), but "%{name}" *does* evaluate to "mup". As a result, I end up installing files to the literal path "/usr/share/doc/%{NAME}".

It's not clear to me whether macros are supposed to be case-sensitive or not, but if I echo "%{NAME}" and "%{name}" in my .spec file, I get 2 different answers.

I'm a relatively new packager, and would appreciate any advice from the experts here as to how best to refer to the correct documentation path (i.e. "%{_pkgdocdir}" in rawhide) without having to maintain 2 different spec files.

thanks!

Greg

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux