RPM спецификационен файлов синтаксис

Съдържание

Заглавка

Заглавката на спецификационния файл съдържа важна информация, необходима за изграждане, относно версията на пакета, изходния код, пачовете, зависимостите.

Макро дефиниция

Началото на файла Spec съдържа дефиниции на макроси. Например:

Заглавие, версия, издание

Първият раздел трябва да съдържа името на стандартната версия, версията и етикета:

Кратко резюме, заглавие, източници и корекции

Следващият заглавен раздел трябва да изглежда така:

Както можете да видите, всичко е подредено в линеен ред:

  1. Резюме- кратко описание на пакета (в един ред).
  2. Лиценз- вижте правилата за лицензиране.
  3. Група— пакетът принадлежи към една от групите ROSA.
  4. URLе началната страница на софтуера.
  5. Източник0.— източници.
  6. Кръпка0.— кръпки.

Изходните файлове трябва да започват сSource0, не използвайтеSource:; ако пакетът съдържа един източник, използвайтеSource0, тъй като няма гаранция, че пакетът винаги ще използва един и същ източник. Същото важи и за ключовата думаPatch0; винаги започвайте сPatch0:и никога не използвайтеPatch:. Ако изходният код има URL, откъдето може да бъде получен, тази информация трябва да бъде включена.

Разделите тук са малко по-къси от дефинициите, главно защото дефинициите могат да бъдат по-дълги, ноИзточник,Имеи други тагове не са. Вместо колона 25 използвайте колона 17 или края на втория раздел. Важно е всички стойности на ключовите думи и като цяло съдържанието на втората колона да бъдат подравнени вляво, тъй като товадизайнът е най-четлив.

Име на пачовете

Корекциите трябва да бъдат наименувани по много ясен начин, така че човек да може бързо да разбере коя версия на корекцията е била приложена и откъде идва. Следователно корекциите трябва да следват следната конвенция за именуване: [име_на_пакета]-[версия]-[описание].кръпка:

  • [package_name] е името на пакета, за който се прилага тази корекция, като например shadow-utils или gnupg;
  • [version] е версията на програмата, за която е подготвена корекцията. Ако преправяте пач за нова версия на програмата, не забравяйте да промените името му – т.е. ако сте имали пач foo-1.0-rosa-fix.patch и трябва да го преработите за версия foo-1.2, тогава наименувайте новия пач foo-1.2-rosa-fix.patch. Тъй като пачовете се съхраняват в Git хранилище, използвайте командата git rename за преименуване.
  • [описание] - кратко описание на пластира.

Изграждане на зависимости

Изисква, Остарява, Предоставя, Конфликти и други подобни

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

  1. първо посочете Изисква
  2. след това - Requires(pre), Requires(post) и други подобни
  3. сега Конфликти
  4. и накрая Prov >Описание

Тагът%descriptionе в самия край, той съдържа описаниепакет. Низът трябва да е дълъг 76 знака.

В резултат RPM-спецификацията трябва да изглежда така:

За пакети, които създават множество подпакети, следвайте инструкциите по-горе за всеки подпакет.

Секцията%prepсе намира след всички дефиниции на пакети. Най-малко 2 празни реда трябва да разделят края на секцията%descriptionот%prep. Най-простият раздел%prepизглежда така:

Други споразумения

Системни макроси и потребителски макроси

Системните макроси са макроси, дефинирани в Шаблон:Файл - например%make,%makeinstall_stdи т.н. Системният макрос е нещо, което прави или изчислява нещо. Това означава, че системният макрос не е проста дефиниция, като% , която просто превежда пътя. Системните макроси се записватбезфигурни скоби, например%mkrel, а не% . Дефинираните от потребителя макроси, които включват% или% се записватвфигурни скоби, като например% , а не%_tmpath. Ако всички използват тази конвенция за фигурни скоби, това ще направи файла със спецификации по-лесен за четене.

Ако не сте сигурни дали да използвате фигурни скоби, не забравяйте, че макроси като% връщат стойност (в този случай Шаблон:Файл), докато макрос като%_install_infoвсъщност изпълнява някакъв код.

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

Използването на подобни имена за макроси увеличава четимостта на спецификационния файл.

  • % - ако името нагоре е различно от името на пакета.
  • % - ако версията нагоре е различна от версията на пакета.

Променливи

Променливи, които наистина са променливи, като $RPM_OPT_FLAGS или $RPM_BUILD_ROOT, не трябва да се използват. Вместо това трябва да се използват макроси като% и%. Променливите "$*" се отнасят за конструкции на обвивката, а не за RPM дефиниции.

Регистри на промените

Журналите на промените се съхраняват в журналите на Git. Когато се ангажирате с Git, регистрационният файл става част от получения спецификационен файл (тъй като регистрационните файлове за ангажиране създават регистър на RPM промените по време на изграждане). Съхранявайте записите в дневника достатъчно подробни, за да не се налага да използвате diff по-късно, за да видите промените. Пример за лош запис в журнала:

Такъв запис не казва нищо и който и да е направил тази промяна, няма да може да каже какво е направено в този ангажимент. Вместо това беше необходимо да се напише нещо подобно:

Обработка на източника

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

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

Вместо това е за предпочитане да използвате% /foo в спецификационния файл, тъй като това прави файла по-лесен за четене. Например сравнете:

Изходните файловене трябвада съдържат макроси% и% освен ако не са оригинални изходни файлове нагоре по веригата.

Пач файловете никога не трябва да съдържат макроси% и% .