Golang -paketoinnin ohjeet

Tässä asiakirjassa kuvataan parhaita käytäntöjä Golang-pakettien paketoimiseen. Suurin osa paketoinnista on automatisoitu käyttämällä laajasti makroja.

go2rpm on työkalu, joka automatisoi monet näistä vaiheista. On suositeltavaa kokeilla go2rpm import_path ennen kuin yrität kirjoittaa SPEC:n käsin.

Tuontipolku

Golangissa paketteihin viitataan täydellä URL-osoitteella. Koska tähän URL-osoitteeseen viitataan useissa paikoissa rpmspecissä, aseta perustuontipolku globaaliksi määritteeksi spesifikaatiotiedoston alussa

%global goipath     github.com/kr/pretty

Kaikki makrot, mukaan lukien paketin nimi ja lähde-URL, johdetaan tästä arvosta.

Käytä aikaa sen tarkkaan tunnistamiseen. Sen vaihtaminen myöhemmin on hankalaa.

  • se voi poiketa arkiston URL-osoitteesta;

  • yleensä oikea arvo on se, jota projekti käyttää dokumentaatiossaan, koodausesimerkeissä ja koontivahvistuksissa;

  • käytä gopkg-tuontipolkua kaikissa kooditiloissa, kun projekti käyttää sitä.

Jos yläjuoksu meni sekaisin useiden haarojen ja uudelleennimeämisen jälkeen, sinun on korjattava viittaukset menneisiin nimiin Go-lähdetiedostoissa, mukaan lukien yksikkötestit. Suorita tämä korjaus kohdassa %prep.

Nimeäminen

Lähdepaketit (src.rpm)

  • Golang-lähdepaketit TÄYTYY nimetä niiden päätuontipolun mukaan. Tämä prosessi on automatisoitu makrolla %{goname}. Tämä makro poistaa kaikki isot kirjaimet, "go"-avainsanat ja päällekkäisyydet tuontipolusta.

    Esimerkiksi:

    • tuontipolusta github.com/kr/pretty tulee golang-github-kr-pretty

    • tuontipolusta github.com/DATA-DOG/go-txdb tulee golang-github-data-dog-txdb

    • tuontipolusta github.com/gopherjs/gopherjs tulee golang-github-gopherjs

    Spec tiedostonimen TÄYTYY vastata paketin nimeä.

    Jos et ole varma, mikä makron %{goname} käsittelemä nimi tulee olemaan, rakenna SRPM käyttämällä:

    fedpkg --release f31 srpm

    RPM-tiedoston nimi on se, jota käytetään rpm-spesifikaatioissa ja spesifikaatioiden tiedostonimessä.

  • Lähdepaketit, jotka tarjoavat tunnetun sovelluksen, kuten etcd TÄYTYY nimetä sovelluksen mukaan. Loppukäyttäjät eivät välitä kielestä, jolla heidän sovelluksensa on kirjoitettu. Älä kuitenkaan nimeä paketteja epäselvän apuohjelman binaarin mukaan, jonka paketti sattuu rakentamaan.

Toteutus: %{gorpmname}

%gometa käyttää %{gorpmname}-makroa muodostaakseen %{goname}:n %{goipath}:sta.

%{gorpmname} voi aiheuttaa törmäyksiä

%{gorpmname} yrittää muodostaa ihmisystävällisen ja rpm-yhteensopivan nimen Go-tuontipoluista. Se yksinkertaistaa niitä poistamalla tarpeettomat ja yleiset tarkenteet. Tämän seurauksena on mahdollista, että kaksi eri tuontipolkua tuottaa saman tuloksen. Siinä tapauksessa voit vapaasti säätää tätä tulosta manuaalisesti välttääksesi törmäyksen.

Go-koodipaketit: %{goname}-devel

Lähdepaketissa, joka on omistettu Go-koodin tarjoamiseen

Pakettien, jotka tarjotaan Go-koodin muodossa %{goipath}, tulee nimetä %{goname}-devel. Jos lähdepakettisi on jo nimeltään %{goname}, se onnistuu helposti seuraavilla tavoilla:

%package devel
[…]
%description devel
[…]
%files devel -f devel.file-list

Toisentyyppisessä lähdepaketissa

Jos lähdepakettisi nimi on jokin muu kuin %{goname}, sinun TULISI käyttää:

%package -n %{goname}-devel
[…]
%description -n %{goname}-devel
[…]
%files -n %{goname}-devel -f devel.file-list

Erilliset koodipaketit

Ja lopuksi, jos haluat jakaa projektin Go-koodin useisiin paketteihin, voit muodostaa vastaavat nimet seuraavasti:

%global goname1 %gorpmname importpath1
[…]
%package -n %{goname1}-devel
[…]
%description -n %{goname1}-devel
[…]
%files -n %{goname1}-devel -f %{goname1}.file-list

Muista, että Go:lle jokainen hakemisto on paketti. Älä koskaan laita yhdessä hakemistossa olevia .go-tiedostoja eri paketteihin.

Tuo polun yhteensopivuuspaketit: %{compat-%{oldgoname}-devel}

Kun projektiin voidaan viitata useilla tuontipoluilla haaroittamisen, uudelleennimeämisen, uudelleenisännöinnin, organisaatiomuutosten tai hämmentävän projektidokumentaation vuoksi, on mahdollista luoda yhteensopivuusalipaketteja koodin yhdistämiseksi, joka käyttää jotakin muista tuontipoluista kanoniseen tiedostoon.

Kanonisen tuontipolun PITÄÄ aina olla se, johon projektidokumentaatiossa viitataan. Jotkut projektit eivät kuitenkaan dokumentoi tuontipolun muutoksia ja luottavat HTTPS-uudelleenohjauksiin (esimerkiksi https://github.com/docker/dockerhttps://github.com/moby/moby). Tällainen uudelleenohjaus on riittävä osoitus siitä, että kanoninen tuontipolku on muuttunut (mutta varmista yläjuoksusta).

Uuden tuontipolun PITÄISI näkyä %{goipath}:ssa ja yhteensopivuuden tuontipolut TÄYTYY ilmoittaa goaltipaths-makron kanssa:

# Välilyönnillä eroteltu luettelo simuloitavista tuontipoluista.
%global goaltipaths

Esimerkiksi Go-kirjasto github.com/Sirupsen/logrus nimettiin uudelleen github.com/sirupsen/logrus, ja dokumentaatio heijastelee tätä uutta tuontipolkua. Pakkaajan TULISI siis pyytää pakettinsa uudelleennimeämistä uudella tuontipolulla ja yhteensopivuuden tuontipolulla:

%global goipath     github.com/sirupsen/logrus
%global goaltipaths github.com/Sirupsen/logrus

Jos projekti on nimennyt useita uudelleen, voidaan myös määrittää useita yhteensopivuuden tuontipolkuja.

Älä koskaan lykkää uudelleennimeämistä

Pakkaajat EIVÄT SAA käyttää tuontipolun yhteensopivuuden alipaketteja aliaksena kanonisen tuontipolun johonkin aiemmista nimistä. Pakkaajien TÄYTYY soveltaa yläjuoksun uudelleennimeämisvalintoja päämuuttujaan %{goipath} ja kaikkeen, mikä siitä johtuu, kuten %{goname}. Lykätyt uudelleennimeämiset aiheuttavat kitkaa yläjuoksun ja muiden pakkaajien kanssa.

GO binääripaketit

Rpmspecin tuottamat binäärit PITÄÄ yleensä listata pääpaketissa. Jos kuitenkin haluat sopivamman nimen tai jakaa binäärit eri pakettien kesken, voit luoda lisää binäärialipaketteja. Tietenkään nämä paketit EIVÄT SAA olla noarch.

Voimme esimerkiksi luoda paketin bbolt, joka sisältää samannimisen binäärin:

%package -n bbolt
[…]
%description -n bbolt
[…]
%files -n bbolt
%license LICENSE
%{_bindir}/bbolt

Versiointi

Monet Go-kirjastot eivät käytä pakettiversioita eikä niillä ole säännöllisiä julkaisuja, vaan niitä ylläpidetään sen sijaan julkisessa versionhallinnassa. Noudata tässä tapauksessa tavallisia Fedora-version käytäntöjä. Tämä tarkoittaa, että usein Go-pakettien versionumero on 0 ja julkaisunumero kuten 0.10.20190319git27435c6.

Suurin osa tästä prosessista on automatisoitu makrojen avulla , joten sinun ei tarvitse määrittää julkaisunumeroa itse.

Määritä ensin otsikossa joko versio, tagi tai kommitti.

Version:
%global tag
%global commit

Käytä sitten makroa %gometa:

%gometa

%gometa-makro käsittelee automaattisesti %{?dist}-tunnisteen Release-kentässä ottaakseen mahdollisen kommitin huomioon.

Kommitit verrattuna julkaisuihin

Sinun PITÄISI paketoida julkaisut ensin. Palkitse projekteja, jotka pyrkivät tunnistamaan vakaat kooditilat. Palaa kommitteihin vain, kun projekti ei julkistu, kun julkaisu on yli kuusi kuukautta vanha tai jos tarvitset ehdottomasti jonkin myöhemmän kommitin muutoksista. Jälkimmäisissä tapauksissa ilmoita projektille kohteliaasti, miksi sinun piti luopua heidän virallisista julkaisuistaan. Julkaisujen mainostaminen on tapa rajoittaa yhteensopimattomien kommittien kaaosta.

Go kielen arkkitehtuurit

Golang- ja gcc-go-kääntäjät ovat saatavilla eri arkkitehtuurien kääntämiseen. Golang-kääntäjä tukee tällä hetkellä arkkitehtuureita x86, x86_64, ppc64le, ppc64 (osittain, katso yläjuoksun numero #13192), s390x, armv7hl ja aarch64.

Binäärien PITÄISI asettaa ExclusiveArch niin, että yritämme rakentaa paketteja vain näille arkkitehtuureille. Makro %gometa lisää tämän nyt automaattisesti hyödyntämällä makroa %{go_arches}.

Riippuvuudet

Paketeissa TÄYTYY olla BuildRequires: go-rpm-macros.

Tämä on automatisoitu makrolla "%gometa".

Automaattinen riippuvuuksien asetus

Useimmat golang-* -paketit ovat vain lähdekoodia. *-devel-alipaketissa, joka sisältää lähdekoodin, tulisi nimenomaisesti määrittää pakettien tarjoajat sen sisältämille golang-tuonneille. Nämä tarjoajat johdetaan automaattisesti tuontipoluista.

Nämä tuonnit sisältävät binäärikoosteet käyttävät niitä BuildRequires:issa, esimerkiksi:

BuildRequires: golang(github.com/gorilla/context)

Niputettuna vai erillään

Tällä hetkellä Fedoraan paketoidut golang-projektit PITÄISI olla oletusarvoisesti erillisiä. Se tarkoittaa, että projektit rakennetaan Fedoralle paketoiduista riippuvuuksista.

Joissakin projekteissa voi olla järkevää rakentaa niputetuista riippuvuuksista. Jokainen niputtaminen tarvitsee asianmukaisen perustelun.

BuildRequires

Projektin BuildRequires sisältää yksikkötestien ja binäärien tarvitsemat riippuvuudet.

Voit kerätä ne manuaalisesti komennolla golist. Esimerkki:

 export GOPATH=/home/user/go
 export goipath="github.com/sirupsen/logrus"
 go get $goipath
 (sort -u | xargs -I{} echo "BuildRequires:  golang({})") <<< "$(
  golist --imported --package-path $goipath --skip-self
  golist --imported --package-path $goipath --skip-self --tests
 )"

outputs:

BuildRequires:  golang(github.com/stretchr/testify/assert)
BuildRequires:  golang(github.com/stretchr/testify/require)
BuildRequires:  golang(golang.org/x/crypto/ssh/terminal)

Jos koontikohteessa on saatavilla automaattisia koontivaatimuksia, voit käyttää %go_generate_buildrequires-makroa kohdassa `%generate_buildrequires':

%generate_buildrequires
%go_generate_buildrequires

Tämä makro hyödyntää golist:iä koontiriippuvuuksien keräämiseen ja riippuvuuksien testaamiseen pakettilähteestä.

Testaus

Sinun TÄYTYY suorittaa yksikkötestejä. Go-kehityksen luonteesta johtuen, erityisesti semanttisen versioinnin käytön puutteesta johtuen API:n rikkoontumisia on usein. Ne on havaittava ajoissa ja käsiteltävä yläjuoksun kanssa.

Jotkin testit voidaan poistaa käytöstä, erityisesti seuraavanlaiset yksikkötestit eivät ole yhteensopivia suojatun rakennusympäristön, kuten mockin, kanssa:

  • testit, jotka kutsuvat etäpalvelinta tai API:a Internetin kautta,

  • testit, jotka yrittävät määrittää järjestelmän uudelleen,

  • testit, jotka perustuvat tiettyyn järjestelmässä käynnissä olevaan sovellukseen, kuten tietokantaan tai lokipalvelimeen.

Jos testi on rikki jostain muusta syystä, voit poistaa sen käytöstä samalla tavalla. Sinun PITÄÄ kuitenkin ilmoittaa ongelmasta myös yläjuoksulle. Muista jäljittää kommentissa, miksi jokainen tarkistus poistettiin käytöstä, ja linkit mahdollisiin yläjuoksun ongelmaraportteihin.

Läpikäyntiohje

Tässä luvussa esitellään vaiheittain tyypillinen Go-määritystiedosto kommentteineen ja selityksineen.

Spec johdanto: %{goipath}, %{forgeurl} ja %gometa

Tavallinen tapaus

Go-paketti tunnistetaan sen tuontipolun perusteella. Go spec-tiedosto alkaa siksi %{goipath}-ilmoituksella. Älä määritä sitä väärin, se määrittää spec tiedoston muita toimintoja.

%global goipath    google.golang.org/api

Jos pakettia isännöidään versionhallinnassa, kuten GitHub, GitLab, Bitbucket tai Pagure, Go-paketin isännöinti päätellään automaattisesti tästä muuttujasta (yleensä lisäämällä sen eteen https://). Jos näin ei ole, sinun on ilmoitettava selkeästi isännöinti-URL makrolla %{forgeurl}

%global forgeurl    https://github.com/google/google-api-go-client

Määritystä %{forgeurl} seuraa joko Version, commit tai tag. Käytä yhdistelmää, joka vastaa käyttötapaustasi.

%global commit     2dc3ad4d67ba9a37200c5702d36687a940df1111

Voit myös määrittää date:n ohittaaksesi lähdearkiston mtime-ajan.

Nyt kun meillä on kaikki tarvittavat muuttujat, %gometa-makro voidaan suorittaa

%gometa

Se päättelee ja asettaa seuraavat muuttujat, jos paketoija ei ole jo asettanut niitä:

goname

rpm-yhteensopiva paketin nimi, joka on johdettu määritteestä goipath

gosource

URL-osoite, jota voidaan käyttää SourceX: arvona

gourl

URL-osoite, jota voidaan käyttää URL:n arvona

Se delegoi käsittelyn %forgemeta-makrolle:

forgesource

URL-osoite, jota voidaan käyttää SourceX: arvona

forgesetupargs

oikeat argumentit välitettäväksi %setup tälle lähteelle, joita %forgesetup ja %forgeautosetup käyttävät

archivename

lähdearkiston tiedostonimi ilman tiedostopäätteitä

archiveext

lähdearkiston tiedostopäätteet ilman etummaista pistettä

archiveurl

URL-osoite, jota voidaan käyttää lähdearkiston lataamiseen ilman uudelleennimeämistä

topdir

lähdearkiston ylin hakemisto (voi olla tyhjä)

extractdir

lähdehakemisto, joka on luotu hakemistoon %{_builddir}, kun on käytetty komentoa %forgesetup, %forgeautosetup tai %{forgesetupargs}

repo

ohjelmistolähteen nimi

omistaja

ohjelmistolähteen omistaja (jos sitä käyttää joku toinen päätelty muuttuja)

shortcommit

versionhallinnan käyttämä commit hash -kiinnitys, jos sellainen on

scm

scm-tyyppi, kun paketoit koodin tilannevedoksia: kommitoinnit tai tagit

distprefix

etuliite, joka on lisättävä kohtaan dist, jotta voidaan jäljittää ei-julkaistu paketointi

Suurin osa päätellyistä muuttujista on sekä ohitettavia että valinnaisia.

Voimme nyt lisätä muut johdanto-osan elementit. Ensinnäkin voimme määrittää monirivisen kuvauslohkon, joka jaetaan alipakettien kesken:

%global common_description %{expand:
cmux on yleinen Go-kirjasto monistaa yhteyksiä niiden hyötykuorman perusteella.
Käyttämällä cmuxia voit tuottaa gRPC:tä, SSH:ta, HTTPS:ää, HTTP:tä, Go RPC:tä ja melkein mitä tahansa
toista protokollaa samassa TCP-kuuntelijassa.}

Tämän kuvaus EI SAA olla yli 80 merkkiä riviä kohden.

Jos tarvitset erityisen kehitysyhteenvedon ja kuvauksen, voit myös määritellä:

  • %global godevelsummary

  • %global godeveldescription

Sitten meidän TÄYTYY määrittää lisenssitiedostot, jotka lisätään devel-alipakettiin:

%global golicenses: Välilyönnillä eroteltu luettelo projektilisenssitiedostoja vastaavista komentotulkki globeista.

Ja mahdolliset asiakirjat, jotka PITÄISI sisällyttää:

%global godocs: Välilyönnillä eroteltu luettelo komentotulkki globeista, jotka vastaavat projektin dokumentaatiotiedostoja. Go rpm -makrot poimivat oletusarvoisesti ".md"-tiedostot ilman tätä.

Voit myös poissulkea tiedostoja kohdista %golicense ja %godocs käyttäen:

  • %global golicensesex

  • %global godocsex

Saatat esimerkiksi haluta poissulkea INSTALL*-tiedostot %godocs:sta, koska niitä ei pitäisi tarjota.

Lähdepaketin metatiedot: %{goname}, %{gourl} ja %{gosource}

Voimme ilmoittaa tavalliset rpm-otsikot käyttämällä %gometa:n tuottamia arvoja:

Name:      %{goname}
# Jos ei ole asetettu aiemmin
Version:
Release:   1%{?dist}
Summary:
License:
URL:       %{gourl}
Source:   %{gosource}

Voit korvata ne manuaalisilla määritelmillä. Korvaa esimerkiksi %{gourl} projektin kotisivulla, jos se on olemassa erillään ohjelmistolähteen URL-osoitteesta. Korvaa %{go*}-muuttujia harkitusti vain, kun se lisää arvoa määritetiedostoon ja ymmärrät seuraukset. Muuten lisäät vain huoltointensiivisiä eroja jakeluun.

BuildRequires

Jos niitä ei luoda automaattisesti, voit nyt lisätä pakettien koostamiseen ja yksikkötestauksiin tarvittavat riippuvuudet:

BuildRequires:  golang(github.com/stretchr/testify/assert)
BuildRequires:  golang(github.com/stretchr/testify/require)
BuildRequires:  golang(golang.org/x/crypto/ssh/terminal)

Katso this osa kuinka saada BuildRequires-luettelo manuaalisesti.

Kuvaus

Lisää nyt pääpaketin kuvaus:

%description
%{common_description}

Paketin metatiedot

Go-koodipakettien määrittelyprosessi on automatisoitu makrolla %{gopkg}. Se luo automaattisesti %package ja %description kaikille ensisijaisille tuontipoluille ja yhteensopivuuspoluille.

%gopkg

Jos sinun on luotava vain Go devel -alipaketteja ilman compatia, käytä:

%godevelpkg

Tarvittaessa voit määrittää yhden tai useampia Go-paketteja, jotka sisältävät koostettavat binaarit. Katso edellinen [Go binary packages] -osio.

%prep: %goprep, toimittajan poistaminen

%goprep purkaa Go-lähdearkistot ja luo projektin "GOPATH"-puun, jota käytetään muussa spesifikaatiotiedostossa. Se poistaa toimittajan (paketoidun) koodin: käytä -k-lippua, jos haluat säilyttää tämän toimittajan koodin, ja käsittele sen seuraukset muissa teknisissä osissa.

%goprep

%goprep suorittaa vain toimittajan perustunnistuksen. Se ei löydä kekseliäillä tavoin tehtyä toimittajakooda. Poista manuaalisesti unohtunut toimittajakoodi rivin %goprep jälkeen.

%goprep ei korjaa yläjuoksun lähteitä puolestasi. Koska kaikki makrokutsut, jotka seuraavat %goprep, olettavat puhtaat ongelmattomat lähteet, sinun on korjattava ne heti %goprep-rivin jälkeen:

  • korvaa vanhentuneiden tuontipolkujen kutsut niiden tämänhetkisillä arvolla

  • korjauskoodin ongelmia

  • poista kuollut koodi (jotkut yläjuoksut lähettävät tarkoituksella rikkinäistä lähdekoodia siinä toivossa, että joku korjaa sen)

Korjaukset ja ongelmaraportit PITÄÄ lähettää yläjuoksulle. Jokaisen käytetyn korjaustiedoston PITÄÄ sisältää linkki yläjuoksun virheraporttiin tai yhdistämispyyntöön. Ainakin kommentti PITÄÄ lisätä selittämään korjaustiedoston perusteluja.

Kun paketoit tuontipolun, joka osallistuu riippuvuussilmukkaan, tarvitset käynnistysvaiheen hallitaksesi alkuperäisiä koontiversioita: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping For Go -koodi, se tarkoittaa, että bootstrap-osion pitäisi:

  • poistaa yksikkötestit, jotka tuovat muita silmukan osia

  • poistaa koodi, joka tuo silmukan muita osia

Joskus voidaan ratkaista riippuvuussilmukat yksinkertaisesti jakamalla tietyt alihakemistot erilliseen -devel alipakettiin. Katso myös syklisten riippuvuuksien käsittely.

Automaattiset BuildRequires

Jos BuildRequires-generaattoria tuetaan, voit nyt lisätä ne koontiversioosi:

%generate_buildrequires
%go_generate_buildrequires

Binääritiedoston paketoiminen: %build-osio

Jos paketti on vain lähdepaketti, voit ohittaa tämän %build-osion kokonaan.

Muussa tapauksessa sinun on ensin tunnistettava manuaalisesti koostettavan projektin osat ja miten tulos nimetään. Käytännössä se on mikä tahansa hakemisto, joka sisältää main() Go -osan. Hienot projektit laittavat ne cmd-alihakemistoihin, jotka on nimetty koostettavan komennon mukaan, mikä on mitä dokumentoimme tässä, mutta se ei ole yleinen sääntö. Joskus koko %goipath koostuu yhdeksi binääriksi.

for cmd in cmd/* ; do
  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
done

Asennetaan paketit

Lähdepaketin asennus

Jos paketoit kirjaston, %gopkginstall suorittaa asennusvaiheet kaikille ensisijaisille tuontipoluille ja yhteensopivuuspoluille.

%gopkginstall

Jos sinun tarvitsee asennetaa vain Go devel -alipaketit ilman compat:ia, käytä:

%godevelinstall

Binääripaketin asennus

Binäärien kohdalla luomme yksinkertaisesti hakemiston %{_bindir} buildroot-hakemistoon ja asennamme komennot siihen suoritettavina tiedostoina:

install -m 0755 -vd                     %{buildroot}%{_bindir}
install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/

Ole tietoinen komentojen nimistä, jotka saattavat jo olla Fedorassa. Jos sinulla on epäilyksiä, voit tarkistaa, onko komento jo saatavilla Fedorassa:

dnf whatprovides --disablerepo="*" --enablerepo=rawhide "/usr/bin/$cmd"

Jos näin on, nimeä komento uudelleen parhaaksi näkemälläsi tavalla.

Yksikkötestien suorittaminen: %gocheck

Kuten aiemmin todettiin, sinun TÄYTYY suorittaa yksikkötestejä kohdassa %check:

%gocheck

Usein on kuitenkin tarpeen poistaa jotkut niistä käytöstä. Sinulla on kolme poissulkemismerkkiä tehdäksesi niin:

  • -d <hakemisto>: sulje pois hakemiston <hakemisto> sisältämät tiedostot ei-rekursiivisesti (alihakemistoja ei suljeta pois)

  • -t <puun juuri>: sulje pois <puun juuri> sisältämät tiedostot rekursiivisesti (alihakemistot jätetään pois)

  • -r <regexp>: sulje pois tiedostot, jotka vastaavat <regexp>

Muista dokumentoida, miksi testi on poistettu käytöstä.

%files määrite

Toimitettaessa lähdekoodia

%gopkgfiles käsittelee %install:ssa tuotetun tiedostoluettelon ja lisää tarvittavat lisenssi- ja dokumentaatiotiedostot:

%gopkgfiles

Kun toimitat binääritiedostoja

Binäärit toimitetaan yleensä pääpaketissa. Tämän paketin TÄYTYY sisältää näihin binääreihin liittyvät juridiset tiedostot ja dokumentaation.

%files
%license LICENSE
%doc cmd/foo/README.md
%{_bindir}/*

Esimerkit

Yksinkertainen lähdepaketti

golang-github-stretchr-testify.spec
# https://github.com/stretchr/testify
%global goipath         github.com/stretchr/testify
Version:                1.2.2

%gometa

%global common_description %{expand:
Golang set of packages that provide many tools for testifying
that your code will behave as you intend.

Features include:

 - Easy assertions
 - Mocking
 - Testing suite interfaces and functions}

%global golicenses    LICENSE

Name:           %{goname}
Release:        1%{?dist}
Summary:        Tools for testifying that your code will behave as you intend
License:        BSD
URL:            %{gourl}
Source:         %{gosource}

BuildRequires: golang(github.com/davecgh/go-spew/spew)
BuildRequires: golang(github.com/pmezard/go-difflib/difflib)
BuildRequires: golang(github.com/stretchr/objx)

%description
%{common_description}

%gopkg

%prep
%goprep

%install
%gopkginstall

%check
%gocheck

%gopkgfiles


%changelog
* Thu Mar 21 22:20:22 CET 2019 Robert-André Mauchin <zebob.m@gmail.com> - 1.2.2-1
- First package for Fedora

Pakettien uudelleennimeämisen käsittely

golang-github-sirupsen-logrus.spec
# https://github.com/sirupsen/logrus
%global goipath         github.com/sirupsen/logrus
Version:                1.4.0

%gometa

%global goaltipaths     github.com/Sirupsen/logrus

%global common_description %{expand:
Logrus is a structured logger for Go (golang), completely API compatible with
the standard library logger.}

%global golicenses    LICENSE
%global godocs        *.md

Name:           %{goname}
Release:        1%{?dist}
Summary:        Structured logger for Go
License:        MIT
URL:            %{gourl}
Source:         %{gosource}

BuildRequires: golang(golang.org/x/crypto/ssh/terminal)
BuildRequires: golang(github.com/stretchr/testify/assert)

%description
%{common_description}

%gopkg

%prep
%goprep

%install
%gopkginstall

%check
%gocheck

%gopkgfiles


%changelog
* Wed Oct 31 2018 Robert-André Mauchin <zebob.m@gmail.com> - 1.4.0-1
- First package for Fedora

Yksinkertainen binääripaketti

golang-github-boltdb-bolt.spec
# https://github.com/square/go-jose
%global goipath         gopkg.in/square/go-jose.v2
%global forgeurl        https://github.com/square/go-jose
Version:                2.1.9

%gometa

%global common_description %{expand:
Package jose aims to provide an implementation of the Javascript Object
Signing and Encryption set of standards. This includes support for JSON Web
Encryption, JSON Web Signature, and JSON Web Token standards.}

%global golicenses    LICENSE
%global godocs        *.md

%global godevelheader %{expand:
# The devel package will usually benefit from corresponding project binaries.
Requires:  %{name} = %{version}-%{release}
}

Name:           %{goname}
Release:        1%{?dist}
Summary:        An implementation of JOSE standards (JWE, JWS, JWT) in Go
# Detected licences
# - *No copyright* Apache License (v2.0) at 'LICENSE'
# json/ is BSD
License:        ASL 2.0 and BSD
URL:            %{gourl}
Source:         %{gosource}

BuildRequires: golang(golang.org/x/crypto/ed25519)
BuildRequires: golang(golang.org/x/crypto/pbkdf2)
BuildRequires: golang(github.com/stretchr/testify/assert)
BuildRequires: golang(gopkg.in/alecthomas/kingpin.v2)

%description
%{common_description}

%gopkg

%prep
%goprep

%build
for cmd in jose-util jwk-keygen; do
  %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
done

%install
%gopkginstall
install -m 0755 -vd                     %{buildroot}%{_bindir}
install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/

%check
%gocheck

%files
%license %{golicenses}
%doc %{godocs}
%{_bindir}/*

%gopkgfiles

%changelog
* Thu Mar 21 21:59:10 CET 2019 Robert-André Mauchin <zebob.m@gmail.com> - 2.1.9-1
- First package for Fedora