navody:pokyny_pro_revize_baliku

Pokyny pro revize balíčků

  • rpmlint musí být spuštěn na každý balíček. Výstup by měl být přiložen v revizi.
  • Balíček musí být pojmenován dle pravidel pro pojmenovávání balíčků.
  • Název .spec souboru musí odpovídat základnímu jménu balíčku %{name} ve formátu %{name}.spec, pokud balíček nespadá do výjimek v pravidlech pro pojmenováváni balíčků.
  • Balíček musí vyhovovat pravidlům pro balíčkováni.
  • Balíček musí být licencován open source kompatibilní licencí a musí vyhovovat ostatním pravním požadavkům definovaným v pravidlech pro balíčkování.
  • Položka „License:“ ve .spec souboru balíčku musí souhlasit s licencí obsahu balíčku.
  • Pokud (a jen tehdy pokud) zdrojový balíček obsahuje text licence ve vlastním souboru, pak musí byt tento soubor obsahující text licence uveden v %doc.
  • Ve .spec souboru smí byt použita jen americká Angličtina.
  • .spec soubor MUSÍ být čitelný. Pokud nebude revizor schopný přečíst .spec soubor, nebude možné provést revizi.
  • Zdrojové kódy použité k sestavení balíčku musí být shodné se zdrojovými kódy z upstreamu (původní, oficiální zdrojové kódy) na adrese uvedené ve .spec souboru. Revizoři by měli používat md5sum k ověřování.
  • Balíček musí být úspěšně přeložen a sestaven do binárních rpm alespoň na jedné podporované architektuře.
  • Pokud se balíček na nějaké architektuře nepodaří přeložit, sestavit nebo spustit, pak by měla být tato architektura uvedena ve .spec souboru v položce ExcludeArch. Každá architektura uvedená v ExcludeArch musí mít záznam v bugzille, který obsahuje důvod proč se nepodařilo balíček přeložit, sestavit nebo spustit. Číslo záznamu by pak mělo být uvedeno v komentáři u odpovídající architektury v ExcludeArch. Nové balíčky nebudou mít záznamy v bugzille při revizi, takže by měly uvést tyto důvody přímo v komentářích dokud nebude balíček schválený, až poté vytvořit záznam a vysvětlení v komentařích nahradit číslem chyby v bugzille. (Následující se týká jen Extras) Záznam v bugzille by měl být označen jako blokující jednoho (nebo více) z následujících záznamů, aby se ulehčilo sledování těchto případů: FE-ExcludeArch-x86, FE-ExcludeArch-x64, FE-ExcludeArch-ppc.
  • Všechny sestavovací závislosti musí být uvedeny v položce BuildRequires s výjimkou těch, které jsou uvedeny v sekci výjimek v pravidlech pro balíčkování. Uvádění těchto závislostí v BuildRequires je volitelné. Používejte zdravý rozum.
  • .spec soubor MUSÍ pracovat správně s locales. Toho se docílí použitím makra %find_lang. Použivání %{_datadir}/local/* je přísně zakázáno.
  • Každý binární RPM balíček, který ukládá sdílené knihovny (nejen symbolické odkazy) do jakéhokoliv ze standardních adresářů linkeru, musí spustit ldconfig v %post a %postun. Pokud má balíček více podbalíčků s knihovnama, pak by měl mít každý z nich taky %post/%postun sekci, která spustí ldconfig. Příklad správného použití:
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
  • Balíček musí být vlastníkem všech adresářů, které vytváří. Pokud nevytváří nějaký adresář, který používá, pak by měl mít závislost na balíčku, který tento adresář vytváří,vlastní. Výjimky v těchto případech jsou adresáře uvedené v Filesystem Hierarchy Standard.
  • Pokud je balíček vytvořen jako „přemístitelný“, musí jeho tvůrce tuto skutečnost uvést v požadavku na revizi spolu s vysvětlením/obhajobou této vlastnosti. Bez tohoto je použití Prefix: /usr považováno za blokující.
  • Balíček nesmí obsahovat duplikáty v seznamu %files.
  • Práva u souboru musí byt správně nastaveny. Např. spustitelné soubory musí mít nastaven příznak spustitelnosti (+x). Každá sekce %files musí obsahovat řádek s %defattr(…).
  • Každý balíček musí mít sekci %clean, která obsahuje rm -rf %{buidlroot}.
  • Každý balíček musí konzistentně používat makra, jak je popsáno v sekci makra v pravidlech pro balíčkování.
  • Každý balíček musí obsahovat kód nebo přípustný obsah. Detailnější vysvětlení najdete v sekci kód vs. obsah v pravidlech pro balíčkování.
  • Rozsáhlé soubory s dokumentací by měly být v -doc podbalíčku. (definice pojmu „rozsáhlá dokumentace“ je ponechána na tvůrci balíčku, nemusí přímo znamenat velikost souboru s dokumentací)
  • Pokud balíček obsahuje cokoliv v %doc, nesmí to ovlivňovat běh programu. Řečeno jinak: Pokud je něco v %doc, program musí fungovat i bez toho.
  • Hlavičkové soubory nebo statické knihovny musí být v -devel podbalíčku.
  • Balíček, který obsahuje pkgconfig(.pc) soubory musí mít závislost na pkgconfig (Requires: pkgconfig).
  • Pokud balíček obsahuje knihovny s příponou (např. libfoo.so.1.1), pak musí být knihovny končící na .so (bez přípony) v -devel podbalíčku.
  • V nejhorším případě, -devel balíček musí být závislý na hlavním balíčku pomocí plné (celé) verze: Requires: %{name} = %{version}-%{release}
  • Balíček nesmí obsahovat žádné .la libtool archivy.
  • Balíčky obsahující GUI aplikace musí obsahovat %{name}.desktop soubor a tento musí být nainstalován pomocí desktop-file-install v %install sekci. Detailněji je toto popsané v pravidlech pro balíčkování v sekci Desktopové soubory. Pokud si myslíte, že vaše GUI aplikace nepotřebuje .desktop soubor, tak byste to měli vysvětlit komentářem ve .spec souboru.
  • Balíček nesmí vlastnit soubory nebo adresáře, které už vlastní jiný balíček. Pokud si myslíte, ze máte důvody k tomu, aby váš balíček vlastnil soubory nebo adresáře jiného balíčku, tak to uveďte při revizi (při požadavku o revizi).
  • Pokud zdrojový balíček neobsahuje soubor s licencí, pak by měl tvůrce balíčku požádat upstream o jeho zařazení (vytvoření).
  • Sekce 'Description:' a 'Summary:' (zkrácený popis) ve .spec souboru by měly obsahovat překlady pro podporované neanglické jazyky, pokud jsou dostupné.
  • Revizor by měl ověřit, ze se balíček správně sestaví v mocku (viz. mock).
  • Balíček by se měl zkompilovat a sestavit do binárních rpm na všech podporovaných architekturách.
  • Revizor by měl ověřit, že balíček funguje jak má. Balíček nesmí segfaultovat (padat:]) apod.
  • Pokud balíček obsahuje skripty měl by revizor ověřit jejich správnou funkčnost a smysluplnost. Rozhodování o smysluplnosti je ponecháno zcela na soudnosti inkvizitora.
  • Podbalíčky jiné než -devel by měly záviset na hlavním (základním) balíčku pomocí plné (celé) verze.
  • Umístění pkgconfig(.pc) souboru závisí na jejich použití. Většinou slouží pro vývojové záležitosti, takže by měly být v -devel balíčku. Odůvodněnou výjimkou jsou balíčky, které jsou sami o sobě vývojové (k vývojovým účelům), které nejsou instalovány v uživatelském prostředí. Např. gcc nebo gdb.
  • Poslední úprava: 2022/11/14 12:25
  • autor: 127.0.0.1