RPM синтаксис spec файлу

Зміст

Заголовок (Spec Header)

Заголовок Spec-файлу містить важливу інформацію, необхідну для складання, про версію пакета, вихідний код, патчі, залежність.

Визначення макросів

На початку Spec-файлу містяться визначення макросів. Наприклад:

Назва, версія, реліз

Перший розділ повинен містити стандартну назву, версію та тег релізу:

Коротке зведення, назва, вихідники та патчі

Наступний розділ заголовка має виглядати так:

Як бачите, все розташовується в лінійному порядку:

  1. Summary- короткий опис пакета (в один рядок).
  2. License- див. Політика ліцензування.
  3. Group- приналежність пакета до однієї з груп ROSA.
  4. URL— домашня сторінка ПЗ.
  5. Source0.- Вихідники.
  6. Patch0.- патчі.

Файли вихідних файлів повинні починатися зSource0, не використовуйтеSource:; якщо в пакеті міститься єдиний вихідний вихід, використовуйтеSource0, оскільки немає гарантії, що в пакеті завжди буде використовуватися один вихідний код. Те саме стосується ключового словаPatch0; завжди починайте зPatch0:, і ніколи не використовуйтеPatch:. Якщо вихідний код має URL, яким його можна отримати, то цю інформацію необхідно включити.

Табуляції тут трохи коротше, ніж визначення, головним чином тому, що визначення можуть бути довшими, алеSource,Nameта ін тегів це не стосується. Замість стовпця 25 використовуйте стовпець 17 або кінець другої табуляції. Важливо, щоб усі значення ключових слів і взагалі вміст другої колонки було вирівняно по лівому краю, оскільки такеоформлення найзручніше для читання.

Найменування патчів

Патчам повинні даватися імена в дуже ясній манері, щоб можна швидко зрозуміти, яка версія патча була застосована і звідки він був узятий. Тому патчі повинні задовольняти таку угоду про найменування: [назва_пакета]-[версія]-[опис].patch:

  • [назва_пакета] - назва пакета, до якого застосовується даний патч, наприклад, shadow-utils або gnupg;
  • [версія] - це версія програми, на яку підготовлений патч. Якщо ви переробляєте патч для нової версії програми, не забудьте змінити його ім'я - тобто якщо у вас був foo-1.0-rosa-fix.patch і вам довелося його переробити для версії foo-1.2, то назвіть новий патч foo-1.2 -rosa-fix.patch. Оскільки патчі зберігаються в Git-репозиторії, використовуйте команду git rename для перейменування.
  • [Опис] - Короткий опис патча.

Залежність складання

Requires, Obsoletes, Provides, Conflicts тощо

Останній набір тегів у заголовку RPM вказує, що пакет надає (тег Provides; такі можливості можна потім вказувати в тегах Requires і BuildRequires інших пакетів), які пакети він робить застарілими (тег Obsoletes), з якими пакетами конфліктує (тег Conflicts) і від яких залежить (тег Requires); зверніть увагу, що у дужках після цього тега можна додатково вказувати ключові слова post-, pre-і так далі, якщо залежність потрібна для виконання відповідних скриптів).

  1. спочатку вказувати Requires
  2. потім - Requires(pre), Requires(post) та подібні
  3. тепер Conflicts
  4. і, нарешті, Prov >Опис

Тег%descriptionзнаходиться в самому кінці, в ньому міститься описпакет. Довжина рядка має становити 76 символів.

У результаті, RPM-spec має виглядати так:

Для пакетів, які створюють кілька підпакетів, дотримуйтесь наведеного вище посібника для кожного підпакета.

Розділ%prepзнаходиться після всіх визначень пакета. Принаймні два порожні рядки повинні відокремлювати кінець розділу%descriptionвід%prep. Найпростіший розділ%prepвиглядає так:

Інші угоди

Системні макроси та макроси користувача

Системні макросами є макроси, визначені у файлах Шаблон:Файл - наприклад,%make,%makeinstall_stdта ін. Системний макрос - це щось, що виконує що-небудь або що обчислює що-небудь. Т. е. системний макрос це не просте визначення, наприклад як%, яке просто переводить шлях. Системні макроси записуютьсябезфігурних дужок, наприклад,%mkrel, а не% . Макроси, визначені користувачем, які включають% або% записуютьсявфігурних дужках, наприклад,% , а не%_tmppath. Якщо всі будуть використовувати цю угоду про фігурні дужки, це спростить читання spec-файлу.

Якщо ви не впевнені, чи використовувати фігурні дужки, пам'ятайте, що макроси, подібні% , віддають значення (в даному випадку, Шаблон:Файл), тоді як макрос, подібний%_install_infoдійсно виконує деякий код.

Стандартні макроси

За умови використання подібних назв для макросів підвищується читабельність spec-файлу.

  • % — якщо апстрім-назва відрізняється від назви пакета.
  • % — якщо апстрім-версія відрізняється від версії пакета.

Змінні

Змінні, які є змінними, наприклад $RPM_OPT_FLAGS або $RPM_BUILD_ROOT, не повинні використовуватися. Замість них повинні використовувати макроси, подібні% і%. Змінні "$*" відносяться до конструкцій оболонки, але не до RPM-визначень.

Журнали змін

Журнали змін зберігаються у журналах Git. При виконанні комміта в Git журнал стає частиною підсумкового spec-файлу (бо журнали комміту створюють журнал змін RPM під час складання). Робіть записи в журналі досить докладними, щоб пізніше не доводилося використовувати diff для перегляду змін. Приклад поганого запису в журналі:

Подібний запис ні про що не говорить і, хто б не зробив цю зміну, він не зможе сказати, що було зроблено в цьому коміті. Натомість треба було записати щось у цьому дусі:

Обробка вихідників

Файли вихідного коду зазвичай обробляються макросом%, але це неефективно з кількох простих причин:

  • немає необхідності стрибати вгору-вниз по spec-файлу, щоб знайти, що, наприклад, означає% ;
  • файли вихідного коду можна легко перенумерувати без необхідності внесення численних змін.

Замість, у spec-файлі переважно використовувати% /foo, тому що це полегшує читання файлу. Наприклад, порівняйте:

Файли вихідного кодуне повиннімістити макросів% і% , якщо вони не є оригінальними файлами вихідного коду з апстриму.

Файли патчів ніколи не повинні містити макросів% та% .