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
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.
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 |
Nimeäminen
Lähdepaketit (src.rpm)
-
Golang source packages dedicated to providing code MUST be named after their main import path. This process is automated by the
%{goname}
macro. This macro will remove any capitalization, "go" keywords, and any duplication in the import path.Esimerkiksi:
-
tuontipolusta
github.com/kr/pretty
tuleegolang-github-kr-pretty
-
tuontipolusta
github.com/DATA-DOG/go-txdb
tuleegolang-github-data-dog-txdb
-
tuontipolusta
github.com/gopherjs/gopherjs
tuleegolang-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.
|
Go-koodipaketit: %{goname}-devel
Lähdepaketissa, joka on omistettu Go-koodin tarjoamiseen
Packages that ship Go code in %{goipath}
should be named %{goname}-devel
. If your source package is already named %{goname}
then:
%package devel
[…]
%description devel
[…]
%files devel -f devel.file-list
This has been automated by the %{gopkg}
and %{gopdevelkg}
macros described in the [Package metadata] section below.
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
Katso myös luku Syklisten riippuvuuksien käsittely.
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/docker → https://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 |
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.
Binaries SHOULD set ExclusiveArch so that we only attempt to build packages on those arches. This is now automatically added by the %gometa
macro by leveraging the %{golang_arches}
macro. Packagers can exclude %ix86
(see Changes/EncourageI686LeafRemoval) by passing -f
to the %gometa
macro. The -f
flag tells %gometa
to set ExclusiveArch: %{golang_arches_future}
instead of ExclusiveArch: %{golang_arches}
. %{golang_arches_future}
includes the same architectures as {golang_arches}
sans %ix86
.
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.
export GOPATH=/home/user/go
export GO111MODULE=off
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ää |
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ä:
|
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
Saatat esimerkiksi haluta poissulkea |
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.
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:
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ä.
Esimerkit
Yksinkertainen lähdepaketti
# 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: MIT
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
# 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
# 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-3-Clause
License: Apache-2.0 AND BSD-3-Clause
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
Want to help? Learn how to contribute to Fedora Docs ›