CPackRPM壓縮手冊頁，然後在包裝過程中找不到它們

雖然創建一個包含人頁（該安裝路徑與已知人的位置列表相匹配）的RPM包，但CPack似乎使用GZip對其進行壓縮，但後來抱怨說原始的未壓縮文件無法找到。那麼應該如何使用該功能呢？CPackRPM壓縮手冊頁，然後在包裝過程中找不到它們

考慮以下的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)

當含有「檢驗。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模塊時，我能夠找到與man page文件混淆的代碼，但找不到用於解決混亂的代碼;前面的代碼無條件地工作， - 我找不到任何可能告訴它不壓縮手冊頁的變量。

我能找到的唯一類似的討論可以追溯到2014年，並通過更新到更新版本的CMake來解決。由於我也是使用openSUSE Linux作爲原始記者（當然是實際版本），我試圖從系統提供的CMake 3.3.2切換到本地構建的3.7.0-rc2，但這並沒有改變事情。因此，考慮到CMake，RPM和man的受歡迎程度，我想如果真的存在一些bug，應該早已修好了，所以責怪我。我在這裏錯過了什麼？

更新。關於使用推薦的通配符， - 我。即指定「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([.].+)?$")

雖然成功的話，仍然沒有回答壓縮形式分發手冊頁的問題。因此，它看起來醜陋和違反直覺。

值得一提的是如何RPM說明文件，從最初發布的CMakeLists.txt產生：

%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應該在配置階段提醒用戶後果甚至發生故障，而不是稍後再隱瞞問題。

來源

2016-11-02 Anton Samsonov

我不熟悉CPackRPM。但這似乎與他們的模板問題，因爲這是rpmbuild功能。當你在％install部分執行：「cp test.2％buildroot/usr/share/man/man1」時，則rpmbuild會在後臺執行壓縮。所以當你放入％files部分「/usr/share/man/man1/test.2」時，它不起作用，因爲它不存在。你必須放在那裏「/usr/share/man/man1/test.2*」。星號在那裏，因爲你實際上不知道rpmbuild是否會使用xz，gz或其他壓縮。 – msuchy

@msuchy我不熟悉rpmbuild，但我清楚地看到，CPackRPM明確處理手冊頁位置並提及「.gz」，儘管僅在註釋中。打包*未壓縮*手冊頁可能是不常見的，以至於沒有人真正測試過。因此，我添加了一個用於轉換和/或壓縮手冊頁的自定義CMake目標 - 這對我來說目前是可接受的解決方案，但我仍然好奇是否可以打包未壓縮的手冊頁。 –

在％文件的手冊頁輸入後使用通配符將獨立於壓縮打包文件。我想說的是在規範文件的文件％部分，鍵入

/usr/share/man/man1/bash.1*

代替

/usr/share/man/man1/bash.1.gz

。

來源

2016-11-07 19:43:34

除了你的回答重複了@msuchy所說的話，你是否曾經使用CMake嘗試過這樣的解決方案？這是CMake自動生成規格文件，它們不是手動編輯。當然，CMake也允許提供你自己的spec文件，但是這相當於使用CMake的目的，除非你真的需要CPackRPM不支持的特殊規則。 –

問題是，rpm在打包時重新壓縮文件，以便控制所用的標誌。例如。 gzip包含需要禁用的時間戳，才能準確生成文件摘要。各種發行版也可以在通過配置打包時更改壓縮。包裝！=建設：嘗試自動化* .spec生成不夠普遍，沒有大量共享複雜性/複雜性。 –

CPackRPM壓縮手冊頁，然後在包裝過程中找不到它們

回答

相關問題