Pakettien tarkistusohjeet

This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the Fedora packaging list .

Pakettien tarkistusprosessi

Avustajien ja arvostelijoiden PITÄÄ noudattaa Pakettien tarkistusprosessi seuraavin poikkeuksin:

  • FPC myöntää nimenomaisen vapautuksen prosessista, kuten on ilmoitettu tässä.

  • Pakettia ollaan luomassa siten, että saman paketin useita versioita voi esiintyä rinnakkain jakelussa (tai rinnakkain EPEL:n ja RHEL:n välillä). Paketti on PITÄÄ nimetä oikein xref: Naming.adoc # _multiple_packages_with_the_same_base_name [nimeämisohjeet] mukaan ja EI SAA olla ristiriidassa saman paketin kaikkien muiden versioiden kanssa.

  • Paketti on olemassa sekä Fedorassa että RHEL:ssä, mutta pakkaaja haluaa lähettää sen EPEL:ssä vaihtoehtoisella nimellä (kuten EPEL:n käytäntö edellyttää) alipaketin tarjoamiseksi. joka on olemassa Fedorassa, mutta jota ei ole (tai ei toimiteta) RHEL:ssä.

Tarkastettavia asioita

Tarkistettavaksi on monia asioita. Tämän luettelon tarkoituksena on auttaa uusia arvostelijoita tunnistamaan alueet, joita heidän tulisi etsiä, mutta se ei ole missään nimessä täydellinen. Tarkastajien tulisi käyttää omaa harkintaansa arvioidessaan paketteja. Luetellut tuotteet jaetaan kahteen luokkaan: PITÄISI ja PITÄÄ.

  • MUST: rpmlint on suoritettava lähdekierrosluvulla ja kaikilla koontiversion tuottamilla binäärikierroksilla. Tulos tulee julkaista katsauksessa. Katso Pakkausohjeet: Käytä rpmlint

  • MUST: Paketti on nimettävä Paketin nimeämisohjeet mukaisesti.

  • MUST: Teknisen tiedoston nimen on vastattava peruspakettia %{name} muodossa %{name}.spec, ellei paketissasi ole poikkeusta. Katso Pakkausohjeet: määritystiedoston nimeäminen .

  • MUST: Paketin on täytettävä Pakkausohjeet.

  • MUST: Paketti on lisensoitu Fedoran hyväksymällä lisenssillä ja sen on täytettävä Lisenssiohjeet.

  • MUST: Paketin tietotiedoston Lisenssi-kentän on vastattava todellista lisenssiä. Katso Lisenssiohjeet: Kelvolliset lisenssin lyhyet nimet

  • MUST: Jos ja vain jos lähdepaketti sisältää lisenssien tekstin omassa tiedostossaan, paketin lisenssien tekstin sisältävä tiedosto on sisällytettävä "%license" -tiedostoon. Katso Lisenssiohjeet: Lisenssiteksti

  • MUST: Tekninen tiedosto on kirjoitettava amerikanenglanniksi. Katso Pakkausohjeet: Yhteenveto ja kuvaus

  • MUST: Paketin määrittelytiedoston PITÄÄ olla luettavissa. Katso Pakkausohjeet: määrittelyn luettavuus

  • MUST: Paketin rakentamiseen käytettyjen lähteiden on vastattava ylävirran lähdettä teknisen URL-osoitteen mukaisesti. Tarkistajien tulee käyttää sha256sum-funktiota tähän tehtävään, koska sitä käyttää sources-tiedosto, kun se on tuotu gitiin. Jos tälle paketille ei voida määrittää ylävirran URL-osoitetta, katso Lähde-URL-ohjeet, kuinka voit käsitellä tätä.

  • MUST: Paketin PITÄÄ kääntää ja rakentaa binäärisiksi RPM:iksi vähintään yhdessä ensisijaisessa arkkitehtuurissa. Katso Packaging Guidelines: Arkkitehtuurin tuki

  • MUST: Jos paketin kääntäminen, rakentaminen tai arkkitehtuuri ei onnistu onnistuneesti, kyseiset arkkitehtuurit tulee luetella kohdassa ExcludeArch. Jokaisella ExcludeArch -kohdassa PITÄÄ luetellulla arkkitehtuurilla on oltava Bugzillassa arkkitehtuuri, joka kuvaa syytä, miksi paketti ei käännä/kehi/toimi kyseisellä arkkitehtuurilla. Vikanumero PITÄÄ sijoittaa kommenttiin vastaavan ExcludeArch -rivin viereen. Katso Pakkausohjeet: Arkkitehtuurin koontiepäonnistumiset

  • MUST: Kaikkien koonnin riippuvuuksien on oltava luettelossa "BuildRequires":ssa. Katso Pakkausohjeet: Koontiajan riippuvuudet (BuildRequires)

  • MUST: Teknisen tiedoston TÄYTYY käsitellä kieliasetuksia oikein. Tämä tehdään käyttämällä %find_lang-makroa. %{_datadir}/locale/* on ehdottomasti kielletty. Katso Pakkausohjeet: Kieliasetustiedostojen käsittely

  • MUST: Paketit EIVÄT saa niputtaa järjestelmäkirjastojen kopioita. Katso Pakkausohjeet: Järjestelmäkirjastojen niputtaminen ja monistaminen

  • MUST: Jos paketti on suunniteltu siirrettäväksi, pakkaajan on mainittava tämä seikka tarkastelupyynnössä sekä rationalisoitava kyseisen paketin siirtämistä. Ilman tätä etuliitteen: /usr käyttöä pidetään estäjänä. Katso Pakkauksen ohjeet: Uudelleensijoitettavat paketit

  • MUST: Paketin on omistettava kaikki sen luomat hakemistot. Jos se ei luo käyttämäänsä hakemistoa, sen pitäisi vaatia paketti, joka luo kyseisen hakemiston. Katso Pakkausohjeet: Tiedostojen ja hakemistojen omistajuus

  • MUST: Fedora-paketti ei saa luetella tiedostoa useammin kuin kerran määritetiedoston %files -luetteloissa. (Huomattava poikkeus: lisenssitekstit tietyissä tilanteissa)Katso Pakkausohjeet: Kaksoistiedostot

  • MUST: Tiedostojen käyttöoikeudet on asetettava oikein. Suoritettavat tiedostot tulee asettaa esimerkiksi suoritusoikeuksilla. Katso Pakkausohjeet: Tiedostojen käyttöoikeudet

  • MUST: Jokaisen paketin tulee käyttää makroja johdonmukaisesti. Katso Pakkausohjeet: Makrot

  • MUST: Paketin tulee sisältää koodia tai sallittavaa sisältöä. Katso Mitä voidaan pakata

  • MUST: Suuret dokumentaatiotiedostot on mentävä dokumentaatio-alipakettiin. (Suuren määritelmä jätetään pakkaajan harkintaan, mutta se ei rajoitu kokoon. Suuri voi viitata joko kokoon tai määrään). Katso Pakkausohjeet: Dokumentaatio

  • MUST: Jos paketti sisältää jotain muodossa %doc, se ei saa vaikuttaa sovelluksen ajoaikaan. Yhteenvetona: jos se on tiedostossa %doc, ohjelman on toimittava oikein, jos sitä ei ole. Katso Pakkausohjeet: Dokumentaatio

  • MUST: Staattisten kirjastojen tulee olla staattisessa paketissa. Katso Pakkausohjeet: Staattisten kirjastojen pakkaaminen

  • MUST: Kehitystiedostojen on oltava kehityspaketissa. Katso Pakkausohjeet: Kehityspaketit

  • MUST: Useimmissa tapauksissa kehityspakettien on vaadittava peruspaketti täysin versioidulla riippuvuudella: Requires: %{name}%{?_isa} = %{version}-%{release} Katso Pakkausohjeet: Peruspaketin vaatiminen

  • MUST: Paketit EIVÄT saa sisältää .la libtool -arkistoja; ne on poistettava teknisistä tiedoista, jos niitä rakennetaan. Katso Pakkausohjeet: Staattisten kirjastojen pakkaaminen

  • MUST: GUI-sovelluksia sisältävien pakettien tulee sisältää %{name}.desktop-tiedosto, ja tämä tiedosto on asennettava oikein desktop-file-install-toiminnolla %install-osiossa. Jos koet, että pakattu GUI-sovelluksesi ei tarvitse .desktop-tiedostoa, sinun on lisättävä spesifikaatiotiedostoon kommentti selityksen kera. Katso Pakkausohjeet: Työpöytätiedostot

  • MUST: Paketit eivät saa omistaa muiden pakettien jo omistamia tiedostoja tai hakemistoja. Nyrkkisääntönä tässä on, että ensimmäisenä asennettavan paketin tulee omistaa tiedostot tai hakemistot, joihin muut paketit voivat luottaa. Tämä tarkoittaa esimerkiksi sitä, että mikään Fedoran paketti ei saa koskaan jakaa omistusta minkään filesystem- tai man-paketin omistamien tiedostojen tai hakemistojen kanssa. Jos sinusta tuntuu, että sinulla on hyvä syy omistaa tiedosto tai hakemisto, jonka toinen paketti omistaa, esitä se paketin tarkistuksen yhteydessä. Katso Pakkausohjeet: Tiedoston ja hakemiston omistajuus

  • MUST: Kaikkien rpm-pakettien tiedostonimien on oltava kelvollisia UTF-8. Katso Pakkausohjeet: Ei-ASCII-tiedostojen nimet

  • MUST: Jakeluun lisättävät paketit EIVÄT SAA olla riippuvaisia paketeista, jotka on merkitty vanhentuneiksi. Katso Käytöstä poistavat paketit

  • SHOULD: Jos lähdepaketti ei sisällä lisenssitekstejä erillisenä tiedostona ylävirtaan, pakkaajan PITÄISI kysyä alkupäästä sen sisällyttämiseksi. Katso Lisenssiohjeet: Lisenssiteksti

  • SHOULD: Arvioijan tulee testata, että paketti rakennetaan Mockissa. Katso Mockin käyttäminen pakettikoontien testaamiseen

  • SHOULD: Paketin tulee kääntää ja rakentaa binäärisiksi RPM:iksi kaikissa tuetuissa arkkitehtuureissa. Katso Pakkausohjeet: Arkkitehtuurituki

  • SHOULD: Arvioijan tulee testata, että paketti toimii kuvatulla tavalla. Paketin ei pitäisi "segfault" sen sijaan, että se toimisi esimerkiksi.

  • SHOULD: Jos sovelmia käytetään, niiden on oltava järkeviä. Tämä on epämääräistä, ja se jätetään arvioijien harkintaan mielenterveyden määrittämiseksi. Katso Pakkausohjeet: Sovelmat

  • SHOULD: Yleensä muiden kuin kehitys-alipakettien tulee vaatia peruspakettia, joka käyttää täysin versioitua riippuvuutta. Katso Pakkausohjeet: Peruspaketin vaatiminen

  • SHOULD: Pkgconfig(.pc)-tiedostojen sijoitus riippuu niiden käyttötapauksesta, ja tämä on yleensä kehitystarkoituksiin, joten ne tulisi sijoittaa kehityspakettiin. Kohtuullinen poikkeus on, että itse pääpaketti on kehitystyökalu, jota ei ole asennettu käyttäjän suoritukseen, esim. gcc tai gdb. Katso Pakkausohjeet: Pkgconfig-tiedostot

  • SHOULD:Jos paketilla on tiedostoriippuvuuksia näiden /etc, /bin, /sbin, /usr/bin tai /usr/sbin ulkopuolella, harkitse tiedoston tarjoavan paketin vaatimista itse tiedoston sijaan. Katso Pakkausohjeet: Tiedosto- ja hakemistoriippuvuudet

  • SHOULD: Paketissasi tulisi olla man-sivut binääreille/skripteille. Jos näin ei ole, lisää ne sinne, missä ne ovat järkeviä. Katso Pakkausohjeet: Man-sivut

Huomautus riippuvuuksista

Usein on hyödyllistä toimittaa paketti tarkistettavaksi yhdessä sen riippuvuuksien kanssa erillisinä lippuina. Niin kauan kuin lähettäjä määrittää bugzillan riippuvuudet: ja estää: -kentät oikein, tämä ei ole ongelma, ja on täysin mahdollista tarkistaa nämä paketit ennen kuin koko riippuvuusketju on jakelussa (ylläpitämällä paikallista arkistoa, pakettien rakentaminen ja asentaminen paikallisesti tai Coprin ylläpito).

However, please keep in mind that you cannot do koji builds if all of the build dependencies are not met (because you cannot provide additional dependencies to koji) and when the time comes to build these packages, they must be built in order and you must wait between builds for the dependencies to make it into the appropriate branch of the distribution. This can be automated using side tags and chain builds.

Huomaa myös, että vaikka saatat pystyä todella rakentamaan paketin, koska kaikki sen rakennusajan riippuvuudet täyttyvät, paketti voi silti olla asentamaton (ja siten hyödytön), jos sen runtime riippuvuudet eivät täyty. Pakettia EI TULE rakentaa, jos jokin sen ajonaikaisista riippuvuuksista on tyytymätön.

Viitteet Fedoran pakkausohjeisiin

Want to help? Learn how to contribute to Fedora Docs ›

  翻译：