在创建包含 man 页面的RPM包（安装路径与已知人员位置列表匹配）时，CPack似乎使用GZip压缩它，但后来抱怨原始的未压缩文件不能被发现。那么该如何使用该功能呢？
考虑以下 CMakeLists.txt 项目：
install(FILES test.1 DESTINATION /usr/share/man)
install(FILES test.2 DESTINATION /usr/share/man/man1)
set(CPACK_PACKAGE_NAME "CPackRPM_man_test")
set(CPACK_GENERATOR "RPM")
include(CPack)
当注释掉包含“ test.2 ”的行时，make package操作成功，也就是说，只需打包不的目标文件到一个真正的手册页位置不会造成任何麻烦。但是，处理完整项目时，将输出以下错误消息：
error: File not found: …/_CPack_Packages/Linux/RPM/CPackRPM_man_test-0.1.1-Linux/usr/share/man/man1/test.2
实际上，该文件根本不存在：
$ cd …/_CPack_Packages/Linux/RPM/CPackRPM_man_test-0.1.1-Linux/usr/share/man
$ ls *
test.1
man1:
test.2.gz
值得注意的是，DEB生成器没有这个问题，只是因为CPackDEB仅对原始文件进行操作。在查看 CPackRPM.cmake 模块时，我能够找到与手册页文件混淆的代码，但不能找到负责撤消混乱的代码;前代码无条件地工作， - 我无法发现任何可能告诉它不压缩手册页的变量。
我能找到的唯一类似讨论可以追溯到2014年，并通过更新到更新版本的CMake来解决。由于我也使用openSUSE Linux作为原始记者（实际发布，当然），我试图从系统提供的CMake 3.3.2切换到本地构建的3.7.0-rc2，但这并没有改变事情。因此，考虑到CMake，RPM和man的流行，我想如果真的存在一些bug，它应该很久以前就已经修复了，所以应该责怪的是我。我在这里缺少什么？
更新。关于使用推荐的通配符， - i。即指定“test.2*”而不是“test.2”。 CMake似乎不支持install(FILES …)形式的globbing：它实际上搜索 test.2 * 并在生成RPM spec文件之前失败。但是，通过另一种形式支持几种模式匹配：
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION /usr/share/man/man1 FILES_MATCHING PATTERN *.1*)
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION /usr/share/man/man2 FILES_MATCHING REGEX "^.+[.]2([.].+)?$")
虽然成功了，但它仍然没有回答以未压缩形式分发手册页的问题。因此，它看起来很丑陋和违反直觉。
值得一提的是如何从最初发布的CMakeLists.txt生成RPM spec文件：
%dir "/usr/share/man"
%dir "/usr/share/man/man1"
"/usr/share/man/man1/test.2*"
%config "/usr/share/man/test.1"
%config "/usr/share/man/man1/test.2"
可以清楚地看到，CPackRPM确实在属于已知人员位置时添加了一个额外的通配版源文件名;不幸的是，它仍然保留了原始（未压缩）文件名，这导致失败。也许CMake要么警告用户后果，要么在配置阶段早期失败，而不是稍后隐瞒问题。
答案 0 :(得分：0)
在％文件中的手册页输入后使用通配符将打包文件而不受压缩。我所说的只是输入
/usr/share/man/man1/bash.1*
而不是
/usr/share/man/man1/bash.1.gz
在spec文件的％files部分。