https://bugzilla.redhat.com/show_bug.cgi?id=1186557 --- Comment #5 from Ben Rosser <rosser.bjr@xxxxxxxxx> --- > - To me, 'make -C docs install DESTDIR=%{buildroot}' > is redundant; you could manage all documentation by using %doc macro. This solution arose as a way to correctly split the documentation files between packages; attempting to specify relative paths in %doc caused the documentation to get included in both the main package and the *-doc subpackage. By installing into %{_pkgdocdir} and then specifying what files to include using fixed paths, it worked. There was some FPC discussion about this around the time I was packaging libtifiles2, I seem to recall. This updated documentation guideline was the result: https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation "Marking a relative path with %doc in the %files section will cause RPM to copy the referenced file or directory from %_builddir to the proper location for documentation. Files can also be placed in %_pkgdocdir, and the build scripts of the software being packaged may do this automatically when called in %install. However, mixing these methods is problematic and may result in duplicated or conflicting files, so use of %doc with relative paths and installation of files directly into %_pkgdocdir in the same source package is forbidden." I am not sure why this is not possible in this specific instance, granted. But I sort of decided "this works, may as well go with it..." > - Also, 'make install DESTDIR=%{buildroot}' already installs fr.po Oops! I forgot to remove the %lang(fr) macro, but remembered to add the %find_lang call. I've removed the duplicate definition and - Why do you use %define instead of %global ? Because I forgot to replace the %define that was there with a %global once I learned the correct thing to do. :) Fixed! Re-uploaded. Spec URL: https://tc01.fedorapeople.org/tilp2/libticalcs2.spec SRPM URL: https://tc01.fedorapeople.org/tilp2/libticalcs2-1.1.8-3.fc21.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review