2016-11-02 2 views
0

При создании пакета 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) 

Когда строка, содержащая «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, я смог найти код, который испортит файлы файлов man, но не код, ответственный за отмену беспорядка; прежний код работает безоговорочно, - я не мог обнаружить какую-либо переменную, которая может сказать, что она не сжимает человеческие страницы.

Единственное подобное обсуждение, которое я смог найти, относится к 2014 году и было разрешено путем обновления до более современной версии CMake. Поскольку я также использую openSUSE Linux, как это делал первоначальный репортер (конечно, конечно), я попытался переключиться с системного CMake 3.3.2 на локально построенный 3.7.0-rc2, но это не изменило вещь. Поэтому, учитывая популярность CMake, RPM и человека, я полагаю, что если какая-то ошибка действительно существовала, она должна была быть исправлена ​​давно, поэтому я виноват в этом. Что мне здесь не хватает?


Обновление. Что касается использования подстановочных знаков, которые были рекомендованы, - i. е. указав «test.2*» вместо «test.2». CMake, похоже, не поддерживает globbing в форме install(FILES …): он буквально ищет test.2 * и не работает перед созданием файла спецификации RPM. Несколько видов поиска по шаблону поддерживаются с помощью другой формы однако:

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 должен либо предупредить пользователя о последствиях, либо даже провалиться на ранней стадии конфигурации, а не скрывать проблему в течение более позднего времени.

+0

Я не знаком с CPackRPM. Но это похоже на проблему с их шаблоном, так как это функция rpmbuild. Когда вы в разделе% install выполните: «cp test.2% buildroot/usr/share/man/man1», тогда rpmbuild сделает сжатие на фоне. Поэтому, когда вы помещаете раздел% файлов «/usr/share/man/man1/test.2», это не сработает, потому что его не существует. Вы должны положить туда «/usr/share/man/man1/test.2*». Asterisk существует, потому что вы действительно не знаете, будет ли rpmbuild использовать xz, gz или другое сжатие. – msuchy

+0

@msuchy Я не знаком с rpmbuild, но я ясно вижу, что CPackRPM явно обрабатывает местоположения страниц man и упоминает «.gz», хотя в комментариях. Возможно, что упаковка * несжатой * man-страницы настолько необычна, что на самом деле никто ее не тестировал. Поэтому я добавил пользовательскую цель CMake для конвертирования и/или сжатия man-страниц на лету, - это приемлемое решение для меня в настоящее время, но мне все еще интересно, можно ли упаковать несжатую справочную страницу. –

ответ

0

Использование wild card после записи страницы man в% файлов будет паковать файл независимо от сжатия. Все, что я хочу сказать, это ввести

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

вместо

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

в разделе% файлов файла спецификаций.

+0

Кроме того, ваш ответ повторяет то, что сказал @msuchy, вы когда-нибудь пробовали такое решение, используя CMake? Это то, что CMake автоматически генерирует файлы спецификаций, они не редактируются вручную. Конечно, CMake также позволяет поставлять свой собственный файл спецификации, но это совершенно поражает цель использования CMake, если вы действительно не нуждаетесь в чем-то особенном в своей спецификации, которую CPackRPM не поддерживает. –

+0

Проблема заключается в том, что rpm повторно сжимает файлы во время упаковки, чтобы контролировать используемые флаги. Например. gzip включает отметку времени, которая должна быть отключена, чтобы файлы дайджеста были сгенерированы точно. Различные дистрибутивы также могут изменять сжатие при упаковке через конфигурацию. упаковка! = здание: попытка автоматизированной генерации * .spec является недостаточно общей без большой общей сложности/сложности. –

Смежные вопросы