Bygge bibliotekpakker for rpm-baserte Linux-distribusjoner. Bygge rpm-pakker og sette opp depotet ditt Lage rpm-pakker
Merk følgende! Handlinger i avsnitt 1 og 4 i disse instruksjonene utføres med administrative rettigheter (root)!
1. Installer de nødvendige pakkene for byggeprosessen
# apt-get install rpm-build
2. Installer src.rpm-pakken til den nødvendige programvaren som må monteres
Vi finner og laster ned src.rpm-pakken med den nødvendige programvaren som vi skal bygge, og installerer den (fra brukeren!):
$ rpm -i pakkenavn_versjon.src.rpm
I dette tilfellet vil kilden (kildekoden) til pakken være plassert i ~/RPM/SOURCES , og spesifikasjonen - i ~/RPM/SPECS .
Tilgjengelighet av programvarekildekode og spesifikasjoner, dvs. beskrivelse av byggeprosessen, er en nødvendig og tilstrekkelig betingelse for å bygge en rpm-pakke (eller bygge om for eksempel en pakke fra en nyere gren for en eldre).
3. Pakkemontering
La oss begynne å montere, dette gjøres med kommandoen:
$ rpm -ba --target (i586|x86_64) ~/RPM/SPECS/spec_name of the_required_package_for_build.spec
I dette tilfellet er det nødvendig å utvide brakettene avhengig av arkitekturen som pakken er bygget for.
De kompilerte pakkene vil bli plassert i ~/RPM/RPMS.
Merk:
Du kan gjenoppbygge pakken uten å installere (pakke ut) den slik:
$ rpmbuild --rebuild --target (i586/x86_64) pakkenavn_med_versjon.src.rpm
I dette tilfellet er det også nødvendig å utvide brakettene avhengig av arkitekturen som pakken er bygget for.
Merk: Når det gjelder prosessorer som ikke tilhører x86_64-familien, er indikasjonen "--target i586" i seg selv valgfri (bygget vil fungere uten det, men kompilatoren vil bygge en pakke som er nøyaktig skreddersydd for din type prosessor, og navnet på pakken vil forskjellig fra navnet på pakkene brunsj, for eksempel xxx.athlon.rpm eller xxx.pentium4.rpm). Fraværet av "--target i586"-parameteren under montering garanterer ikke i det hele tatt at pakken kompilert på denne måten kan installeres på en annen datamaskin med en annen prosessor. Hvis sammenstillingen utføres under et 64-bitssystem (på en 64-bits prosessor med et 64-bitssystem installert), mister "--target x86_64"-nøkkelen sin betydning og er ikke nødvendig å sette den i det hele tatt.
Merk: Hvis rpm klager på makroer som ikke ble funnet noe sånt som dette: "feil: Makro %groupadd ikke funnet" eller "feil: Makro %lisens ikke funnet", så bør installasjonen av en av rpm-build-*-pakkene på systemet hjelpe deg videre montering av pakken, som faktisk er en ekstra avhengighet for å bygge (gjenoppbygge) pakken din og er ansvarlig for å tildele de nødvendige verdiene til disse svært ufunne makroene.
4. Installere monteringsavhengigheter
Hvis du har en srpm-pakke som du trenger for å installere avhengigheter for å bygge, kan du gjøre dette ved å kjøre følgende kommando:
# apt-get build-dep pakkenavn_versjon.src.rpm
Hvis det ikke er noen srpm-pakke og det er en egen spesifikasjon og kildekode, vil nesten 100 % av bygget ikke fungere med en gang - helt i begynnelsen av utgangen vil konsollen vise pakker som må installeres på systemet før bygget kan gå lenger. Du installerer dem (disse monteringsavhengighetene vises i konsollen)
# apt-get install pakke1 pakke2 pakke3 ...
og gjenta deretter monteringen (gå tilbake til trinn 3).
5. Automatisk søk etter avhengigheter for en nybygd pakke
Hvis du bygger en ny pakke, og ikke gjenoppbygger en eksisterende srpm, vil verktøyet tjene deg godt i utformingen (søk og registrering) av de nødvendige avhengighetene i spesifikasjonen byggereq fra rpm-utils-pakken:
$ buildreq spec_file_name.spec
Noen ganger kommer du over nyttige programmer som kun er tilgjengelig i kildekodeform (og/eller som installasjonspakker for andre operativsystemer), men det er behov for å installere dem på flere datamaskiner. For ikke å kompilere på hver datamaskin separat, kan du forberede en installasjonspakke på en og installere den ved hjelp av standardverktøy på andre datamaskiner.
Nedenfor er et eksempel på å lage en RPM-pakke for Fedora 21 (prosedyren er den samme for andre versjoner av Fedora) fra kildekoden til det veldig fine og nyttige programmet Boomaga versjon 0.7.0.
Forbereder RPM byggeverktøy
Først prøvde jeg å installere de nødvendige verktøyene (som anbefalt for meg):sudo dnf installer @development-tools, men denne kommandoen mislyktes, med henvisning til fraværet av utviklingsverktøy-gruppen. Så installerte jeg alt med en annen kommando, som ble foreslått for meg:
sudo dnf groupinstall "Utviklingsverktøy" og ytterligere to kommandoer fra begge artiklene ovenfor:
sudo dnf install rpmdevtools sudo dnf install fedora-packager Deretter må du generere et arbeidsområde for å bygge RPM:
rpmdev-setuptree Denne kommandoen vil opprette de nødvendige katalogene i gjeldende brukers hjemmekatalog (som viser innholdet i den nye katalogen rpmbuild):
$ ls ~/rpmbuild/ BYG BUILDROOT RPMS KILDER SPECIFIKASJONER SRPMS Jeg flytter umiddelbart kildearkivet (boomaga-0.7.0.tar.gz) til SOURCES-katalogen, slik den er. Forresten, det er en liten hake fra github - nedlastingslenken er ikke gitt direkte, men genereres først etter å ha klikket på den. På grunn av dette var det ikke mulig å gi en direkte lenke til arkivet på Internett i SPEC-filen, som vil bli diskutert nedenfor.
Klargjør SPEC-filen
For å pakke kildekoden til programmet inn i en RPM-pakke, trenger du en spesiell fil som beskriver de nødvendige handlingene. La oss generere en mal:rpmdev-newspec boomaga Denne kommandoen vil lage filen boomaga.spec i ~/rpmbuild/SPEC-katalogen. Navnet på SPEC-filen er viktig her. Det må samsvare med programnavnet (dvs. uten versjonsnummer). Etter den automatiske genereringen av SPEC-filen fortsetter vi å redigere den. I mitt tilfelle ble det slik:
Navn: boomaga Versjon: 0.7.0 Utgivelse: 1%(?dist) Sammendrag: Boomaga er en virtuell skriver for visning av et dokument før utskrift Lisens: GPLv2 og LGPLv2+ URL: http://boomaga.github.io Kilde0: %(navn )-%(version).tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Krever: kopper %description Boomaga ( BOOklet Manager) er en virtuell skriver for å vise et dokument før du skriver det ut ved hjelp av den fysiske skriveren. Programmet er veldig enkelt å jobbe med. Når du kjører et hvilket som helst program, klikker du på "skriv ut" og velger "Boomaga" for å se Boomaga-vinduet åpne om flere sekunder (CUPS tar litt tid å svare). Hvis du skriver ut ett dokument til, blir det lagt til det forrige, og du kan også skrive dem ut som ett. %prep %setup -q %build mkdir build cd build cmake .. %make_install %files %defattr(0755,root,root,-) /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations /boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local /share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru .qm /usr/local/share/boomaga/translations/ [e-postbeskyttet]/usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps /boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/mime/packages /boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd %attr(0644,root,root) %doc /usr/local/share/man/man1/boomaga.1.gz %changelog * Man 22. juni 2015 Oleg - Alt som kommer etter prosenttegnet er en makro (for eksempel %build) eller en forhåndsdefinert verdi (for eksempel %(navn)). Som det fremgår av Fedora-dokumentasjonen, kan en liste og beskrivelse av alle makroer finnes i katalogene:
- /etc/rpm/*
- /usr/lib/rpm
- /usr/lib/rpm/makros
rpm --showrc La meg kommentere de angitte verdiene.
Parameter Navn må samsvare med navnet på SPEC-filen og navnet på programmet (angitt uten versjonsnummer).
Parameter Kilde0 bør riktig peke til et arkiv på Internett som har samme navn som filen i ~/rpmbuild/SOURCES-katalogen, men fordi Jeg kunne ikke finne en lenke til boomaga-0.7.0.tar.gz på Internett, så jeg indikerte en lokal lenke. Aldri. Bare filnavnet og bruk av variabler (hentet fra parametrene ovenfor med samme navn).
Før jeg prøvde å bygge RPM-pakken, prøvde jeg å kompilere programmet på vanlig måte. For å gjøre dette må du installere verktøyet cmake og avhengigheter til dette programmet: cups-devel, poppler-devel, poppler-cpp-devel, qt5-qtbase-devel, qt5-qttools-devel, snappy-devel. Jeg spesifiserte alle disse pakkene i parameteren Build Krever.
Fordi boomaga kan fungere som en virtuell skriver som et lag mellom CUPS, da spesifiserte jeg kopper i parameteren Krever.
Neste er makroene som vil bli utført når du bygger RPM-pakken.
Etter %beskrivelsesmakroen flytter vi til en ny linje og setter inn en beskrivelse fra prosjektets hjemmeside.
Makroen %setup -q pakker ut kildekoden i katalogen ~/rpmbuild/BUILD/%(name)-%(versjon), dvs. i vårt tilfelle - ~/rpmbuild/BUILD/boomaga-0.7.0
Deretter kommer den viktigste delen. Du må beskrive alt for automatisk kompilering av prosjektet. Jeg gjorde dette. Jeg åpnet de offisielle instruksjonene for å installere denne applikasjonen og endret den for å passe den nåværende situasjonen. Installasjonsinstruksjonene viste seg å være veldig kortfattede og forståelige:
mkdir ~/boomaga/build cd ~/boomaga/build cmake .. make && sudo make install I form av makroer i SPEC-filen ble disse instruksjonene uttrykt som følger:
%build mkdir build cd build cmake .. %make_install Den første makroen %build er ansvarlig for å bygge kildene. I denne fasen lager vi en katalog bygge i gjeldende katalog (dvs. ~/rpmbuild/BUILD/boomaga-0.7.0) og flytt til den. Kjør deretter cmake for å generere Makefilen. De. alt som er skrevet i instruksjonene for normal installasjon av dette programmet.
Deretter vil %make_install-makroen bygge alt i ~/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64-katalogen som om det var en normal installasjon. De. der opprettes en usr-katalog med alle underkatalogene som er involvert.
Makrooperasjonene %filer (her må du spesifisere en liste over alle filene som er inkludert i RPM-pakken) og %doc (all dokumentasjon) ble fylt ut i samsvar med instruksjonene etter de første mislykkede kjøringene - da pakken ble bygget ble meldingen fylt ut. vist:
Behandler filer: boomaga-debuginfo-0.7.0-1.fc21.R.x86_64 Ser etter utpakkede fil(er): /usr/lib/rpm/check-files /home/oleg/rpmbuild/BUILDROOT/boomaga- 0.7.0 -1.fc21.R.x86_64 feil: Fant installert (men ikke pakket) fil(er): /usr/lib/cups/backend/boomaga /usr/lib/cups /filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share /boomaga/translations/boomaga_cs.qm /usr/local /share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it .qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga /translations/boomaga_ru.qm /usr/local/share /boomaga/translations/ [e-postbeskyttet]/usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps /boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1 /boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd Pakkebyggefeil: Fant installert(e) (men ikke pakket) )) fil( s): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/ lib/boomaga/ boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/ share/boomaga/ translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt. local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/ [e-postbeskyttet]/usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps /boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1 /boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd Som et resultat av en vellykket bygging, genereres RPM-pakker:
~/rpmbuild/RPMS/x86_64/boomaga-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/RPMS/x86_64/boomaga-debuginfo-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/SRPMS/boomaga-0.7.0-1.fc21.R.src.rpm
Og her er faktisk hvordan du starter sammenstillingen:
rpmbuild --target=x86_64 -ba ~/rpmbuild/SPECS/boomaga.spec Kommandoen kjører om et par minutter. På dette tidspunktet flyr vakre flerfargede linjer gjennom konsollen.
Senere, når Fedora-distribusjonen oppdateres til neste versjon, kan du prøve å ompakke boomaga-0.7.0-1.fc21.R.src.rpm-pakken med følgende kommando:
rpmbuild --rebuild boomaga-0.7.0-1.fc21.R.src.rpm I teorien vil dette redusere tiden det tar å bygge en RPM-pakke.
For å sjekke SPEC-filen og den genererte pakken, kan du gå til ~/rpmbuild/SPEC-katalogen og bruke kommandoen:
rpmlint boomaga.spec ../SRPMS/boomaga* ../RPMS/*/boomaga* Dette vil vise ulike advarsler og feil. I mitt tilfelle er det filplasseringsfeil. Men til personlig bruk er den også egnet. Selv om slike feil ikke vil bli tillatt i de offisielle depotene.
Du kan se en beskrivelse av feilen ved å angi navnet etter -I-bryteren i følgende kommando:
rpmlint -I hardcoded-library-path
nyttige lenker
Det er ganske mange forskjellige parametere og makroer. Den offisielle Fedora-dokumentasjonen har omfattende, nyttig og omfattende "Hvordan lage en RPM-pakke" og "Packaging:Guidelines". Det er også et eksempel med forklaringer av SPEC-filen i materialet "Annotated spec file".Gjør RPM bedre
For at den resulterende RPM-pakken ikke bare skal utføre funksjonen sin, men også gjøre den riktig, må du bli kvitt alle feilene som er angitt av rpmlint.
Hovedfeilen er at de resulterende filene er installert på systemet på feil sted. For det første må alt være i samsvar med Filesystem Hierarchy Standard, som nylig ble oppdatert. For det andre må RPM-pakken for Fedora overholde reglene for den distribusjonen.
Vi må kvitte oss med hardkodede stier i %filer-delen. Makroer brukes til dette. I mitt tilfelle hadde programkildekoden flere steder en hardkodet sti til lib-underkatalogen, og for x86_64-arkitekturen var det nødvendig å spesifisere lib64. Derfor var det nødvendig å korrigere kildekoden til programmet litt.
Som et resultat av kommunikasjon med programutviklerne på github.com ble SPEC-filen også supplert med automatisk registrering av skriveren i systemet. Pluss at Boomaga-programmet klarte å oppdatere til versjon 0.7.1. Resulterende SPEC-fil:
Navn: boomaga Versjon: 0.7.1 Utgivelse: 1%(?dist) Sammendrag: En virtuell skriver for å se et dokument før utskrift Lisens: GPLv2 og LGPLv2+ URL: http://boomaga.github.io Kilde0: %(navn)- %(version).tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Krever: cups,snappy %description Boomaga ( BOOklet Manager) er en virtuell skriver for å vise et dokument før du skriver det ut ved hjelp av den fysiske skriveren. Programmet er veldig enkelt å jobbe med. Når du kjører et hvilket som helst program, klikker du på "skriv ut" og velger "Boomaga" for å se Boomaga-vinduet åpne om flere sekunder (CUPS tar litt tid å svare). Hvis du skriver ut ett dokument til, blir det lagt til det forrige, og du kan også skrive dem ut som ett, og du kan også skrive dem ut som ett. Uansett om skriveren din støtter tosidig utskrift eller ikke, vil du enkelt kunne skrive ut på begge sider av arket. Hvis skriveren din ikke støtter tosidig utskrift, påpek dette i innstillingene, og Booklet vil be deg om å snu sidene halvveis i utskriften av dokumentet. Programmet kan også hjelpe deg med å få forberedt dokumentene dine litt før utskrift. På dette stadiet gjør Boomaga det mulig å: * Lime inn flere dokumenter sammen. * Skriv ut flere sider på ett ark. * 1, 2, 4, 8 sider per ark * Hefte. Bretter du arkene i to, får du en bok. %prep %setup -q %build %ifarch x86_64 %cmake -DLIB_SUFFIX=64 -DCUPS_BACKEND_DIR=%(_libdir)/cups/backend -DCUPS_FILTER_DIR=%(_libdir)/cups/filter . %else %cmake -DCUPS_BACKEND_DIR=%(_libdir)/cups/backend -DCUPS_FILTER_DIR=%(_libdir)/cups/filter . %endif make %(?_smp_mflags) %install make install DESTDIR=%(buildroot) %__mkdir -p %(buildroot)%(_datadir)/%(name)/scripts %__install -m 755 scripts/installPrinter.sh %(buildroot )%(_datadir)/%(name)/scripts/ chmod +x %(buildroot)%(_datadir)/%(name)/scripts/installPrinter.sh # Legg til oversettelse lang-tags (cd %(buildroot) && finn . - navn "*.qm") | %__sed -e "s|^.||" | sed -e \ "s:\(.*/translations/boomaga_\)\(\+\)\(.*qm$\):%lang(\2) \1\2\3:"\ >> % (navn).lang %pre # Start cups if er stoppet hvis [ "$(systemctl is-active cups.service)" != "active" ]; deretter systemctl start cups sleep 2 fi %post # Installer skriveren til cups backends hvis [$1 = 1 ]; deretter sh %(_datadir)/%(name)/scripts/installPrinter.sh fi %preun # Avinstaller skriveren lpadmin -x "Boomaga" %files %defattr(755,root,root,-) %(_libdir)/cups/ backend/%(name) %defattr(-,root,root,-) %(_libdir)/cups/filter/boomaga_pstopdf %(_bindir)/%(name) %(_libdir)/%(name)/boomagabackend %(_libdir )/%(name)/boomagamerger %(_datadir)/applications/boomaga.desktop %(_datadir)/%(name)/translations/* %(_datadir)/dbus-1/services/org.boomaga.service %(_datadir )/icons/hicolor/* %(_datadir)/mime/packages/boomaga.xml %(_datadir)/ppd/%(name)/boomaga.ppd %(_datadir)/%(name)/scripts/installPrinter.sh % doc KOPIERING GPL LGPL README.md %(_mandir)/man1/boomaga. 1.gz %changelog * Tir 30. jun 2015 Oleg Ekhlakov
RPM-programmet er designet for å utføre alle typer operasjoner med programvare, inkludert å lage installasjonspakker (RPM-pakker).
Før vi beskriver mange tørre fakta hentet fra dokumentasjonen, la oss se på et enkelt eksempel på å lage en liten RPM-pakke. Jeg opprettet denne pakken for programmet mitt, som overvåker tilstanden til den angitte serieporten.
Vi vil anta at programmet allerede er kompilert og at alle filene som er nødvendige for driften allerede er forberedt. Vi trenger følgende filer:
port - kompilert binær fil
README-fil
port.1 - mann hjelpefil
Jeg plasserte alle disse filene i /root/port-katalogen. Dette er selvsagt ikke helt riktig, men dette vil bli diskutert litt senere.
For å lage en pakke må vi lage en spesifikasjonsfil. Spesifikasjonsfilen inneholder all informasjon om pakken som opprettes: navn, versjon, programfiler, dokumentasjonsfiler, handlinger utført ved installasjon av pakken og ved avinstallering.
Her er spesifikasjonsfilen min for portprogrammet
Oppføring 1.
# /root/port/port.spec # Spesifikasjonsfil for portprogrammet # Generell beskrivelse av programmet Sammendrag: Program for å kontrollere den serielle enheten din # Pakkenavn Navn: port # Dens versjon Versjon: 1.0 # Utgivelse Utgivelse: 99 # Programvaregruppe . Grupper (eller kategorier) brukes av mange programmer # for å manipulere pakker, for eksempel gnorpm, som bygger et tre # med kategorier av installert programvare Gruppe: Overvåking # Du kan spesifisere navnet ditt hvis du vil, men dette er vanligvis GPL-lisens: GPL # Du kan også spesifisere copyleft # Opphavsrett: GPL # Pakken vår er ikke i konflikt med noe # Konflikter: # Lederen vil fylle ut dette feltet om nødvendig # (kun for å lage binære pakker!) # Krev: # Informasjon om pakkeoppretteren Packager : Denis Kolisnichenko URL: http://dkws .narod.ru # Tags Sammendrag, Navn, Versjon, Utgivelse, Gruppe, Lisens kreves # Fra informasjonen ovenfor er det klart at en pakke vil bli opprettet: # port-1.0-99 .i686.rpm # Arkitekturen din kan variere # Full beskrivelse av pakken %beskrivelse Portprogrammet er designet for å overvåke statusen til en seriell port. Når et signal (1) mottas på en kontakt for den angitte porten, sender porten en melding til brukeren som startet den til den spesifiserte e-posten # Filer som vil bli plassert i pakken %files %doc /root/port/README / root/port/port /root/port/port.1
For å bygge pakken må du skrive inn kommandoen:
# rpm -bb /root/port/port.spec
Hvis du ikke gjorde noen feil når du opprettet spesifikasjonsfilen, vil du se en melding som ligner denne på skjermen:
Utfører (%install): /bin/sh -e /var/tmp/rpm-tmp.33439 Behandler filer: port-1.0-99 Finner gir: (ved hjelp av /usr/lib/rpm/find-provides)... Finner Krever: (bruker /usr/lib/rpm/find-requires)... Krever: ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) Registrert: /usr/src/RPM /RPMS/i686/port-1.0-99.i686.rpm
Dette vil opprette port-1.0-99.i686.rpm-pakken. Denne pakken vil bli plassert i katalogen /usr/src/RPM/RPMS/i686
La oss gjøre et lite eksperiment. Start Midhight Commander (mc), gå til /usr/src/RPM/RPMS/i686/-katalogen og "skriv inn" port-1.0-99.i686.rpm-pakken som om den var en vanlig katalog. Den vil inneholde en "underkatalog" INFO, som inneholder all informasjon om pakken.
Vel, vi har funnet ut hvordan vi bygger en enkel pakke, men vi har fortsatt ikke nok kunnskap til å lage faktiske installasjonspakker. Nå er det turen til den tørre teorien som jeg nevnte i begynnelsen av artikkelen.
Tradisjonelt består prosedyren for å lage RPM-pakker av følgende trinn:
- Trekker ut programkildekoder fra arkivet
- Kompilere et program fra kilden
- Opprette en RPM-pakke
Du kan hoppe over de to første trinnene, noe vi gjorde da vi lagde pakken vår. Dette kan bare gjøres hvis programmet allerede er kompilert fra kilden.
RPM-programmet bruker rpmrc-konfigurasjonsfilen. Denne filen søkes i katalogene /usr/lib/rpm, /etc, $HOME. Du kan se denne filen ved å bruke kommandoen:
# rpm --showrc
Topdir-oppføringen i rpmrc-konfigurasjonsfilen inneholder navnet på katalogen som inneholder underkatalogtreet som RPM bruker til å bygge pakker. Skriv inn kommandoen:
# rpm --showrc | grep topdir -14: _builddir %(_topdir)/BUILD -14: _rpmdir %(_topdir)/RPMS -14: _sourcedir %(_topdir)/SOURCES -14: _specdir %(_topdir)/SPECS -14: _srcrpmdir %(_topdir) /SRPMS -14: _topdir %(_usrsrc)/RPM
For meg er disse underkatalogene plassert i /usr/src/RPM-katalogen. Som du kan se, inneholder denne katalogen underkataloger BUILD, RPMS, SOURCES, SPECCS, SRPMS.
En RPM-pakke opprettes i BUILD-katalogen. SOURCES-katalogen inneholder komprimert kildekode for programmet. De opprettede pakkene plasseres i RPMS-katalogen. Mer presist er de plassert i en av underkatalogene, som avhenger av arkitekturen. Pakker som inneholder kildekoden til programmet plasseres i SRPMS-katalogen.
SPECS-katalogen inneholder spesifikasjonsfiler. Vanligvis heter spesifikasjonsfilen program_name-version-release.spec.
For eksempel, hvis du har et programs kildekode i en zip-fil som du vil lage en RPM-pakke fra, kopier den til SOURCES-katalogen
# cp source_code-1.0.tar.gz /usr/src/RPM/SOURCES
Som standard fungerer RPM med pakker som ligger i en katalog som heter det samme som pakkenavnet og versjonen. For portpakken vår vil dette være port-1.0-99-katalogen. Pakkebehandlingen vil kompilere pakken vår i katalogen /usr/src/RPM/port-1.0-99
Jeg tror det er nok informasjon om RPM-kataloger allerede. La oss nå gå videre til spesifikasjonsfilen. Spesifikasjonsfilen består av fire segmenter: overskrift, forberedende, fil, installasjon.
Overskriften gir generell informasjon om pakken. I oppføring 1 inkluderer overskriftssegmentet taggene Sammendrag, Navn, Versjon, Utgivelse, Gruppe og Lisens. Vi vil ikke dvele ved dem, siden hensikten deres er tydelig fra liste 1.
Det er også en veldig nyttig tag: BuildRoot. Det endrer plasseringen av BYGG-treet. Standardverdien er /usr/src/RPM eller en annen katalog spesifisert av miljøvariabelen $RPM_BUILD_ROOT. For å spare diskplass er det nyttig å slette %RPM_BUILD_ROOT-treet etter installasjonen. Men standardtreet kan inneholde andre filer som tilhører andre pakker. Derfor må du først, ved å bruke BuildRoot-koden, angi en midlertidig katalog, og etter installasjonen, slette den.
Hvert segment inneholder makrokommandoer. Vi er allerede kjent med noen - disse er %description, %files, %doc, %install. Tabell 1 gir en fullstendig beskrivelse av makroene.
Tabell 1.
| Makro kommando | Beskrivelse |
| %beskrivelse | Full pakkebeskrivelse |
| %prep | Arkivforberedelse. Her spesifiseres kommandoer for å trekke ut kildeteksten til programmet og pakke den ut, samt ytterligere klargjøring av kildeteksten. Makroen %prep etterfølges av vanlige skallkommandoer. |
| %oppsett | Makrokommando for å trekke ut filer fra arkiver. Alternativet -n lar deg spesifisere katalogen der den nye pakken skal opprettes. Vanligvis pakkes arkivet som ligger i SOURCES-katalogen ut i BUILD-katalogen |
| %bygge | Kompileringsmakro. Det er vanligvis her du kjører make-programmet med de nødvendige parameterne |
| %filer | Angir en liste over filer inkludert i pakken. Når du spesifiserer filnavn, må du spesifisere en fullstendig bane, ikke en relativ bane. Du kan bruke miljøvariabelen $RPM_BUILD_ROOT for å spesifisere hele banen. De nødvendige filene skal allerede være plassert i BUILD-katalogen. Dette kan oppnås ved å bruke %setup-makroen eller ved å bruke %pre (se nedenfor) |
| %config liste | Spesifiserer en liste over filer som vil bli plassert i /etc-katalogen |
| %doc liste | Spesifiserer en liste over filer som vil bli plassert i katalogen /usr/doc/--. |
| %installere | Programvareinstallasjonsstadiet. Her må du skrive ned kommandoene som skal installere filene som er inkludert i pakken. Det er mer praktisk å bruke installeringskommandoen, som jeg brukte i oppføring 1 |
| %pre | Handlinger som vil bli utført før du installerer pakken |
| %post | Handlinger som vil bli utført etter installasjon av pakken |
| %preun | Trinn du må ta før du fjerner en pakke |
| %postun | Tiltak som skal iverksettes etter at pakken er fjernet |
| %ren | Fjerning av BUILD-treet. Brukes i stedet for --clean-alternativet til rpm-programmet. Inneholder vanligvis én kommando: rm -rf $RPM_BUILD_ROOT |
Det er et raskt notat angående makroene %config og %doc. I dette tilfellet spesifiseres listen annerledes enn %files-makroen. Hvis du etter %files-makroen ganske enkelt kan spesifisere én fil på hver linje, må i %doc-makroen hver fil (eller hver liste) innledes med en %doc-kommando. For eksempel,
%doc README TODO Endringer %doc Installer og ikke %doc README TODO Endringer Installer
Nok en gang merker jeg at tilstedeværelsen av alle makrokommandoer i spesifikasjonsfilen ikke er obligatorisk.
Når vi opprettet pakken, brukte vi alternativet -bb i rpm-programmet. Hvis du spesifiserer dette alternativet, opprettes bare en binær RPM-pakke hvis du også vil lage en pakke som inneholder programkildekoden, bruk -ba-alternativet. Den opprettede pakken plasseres i SRPMS-katalogen og får navnet port-1.0-99.src.rpm. Det vil si at i stedet for navnet på arkitekturen, vil det bli indikert at denne pakken inneholder kildekoden til programmet. For å lage en slik pakke må kildekoden til programmet være plassert i SOURCES-katalogen.
For å fullføre bildet, gjenstår det å vurdere rpm manager-alternativene som brukes til å lage pakker.
Tabell 2.
| -ba | To pakker opprettes: binærpakken og kildepakken. Dette hopper ikke over noen installasjonstrinn spesifisert i spesifikasjonsfilen |
| -bb | Bare den binære pakken er opprettet. Ingen installasjonstrinn spesifisert i spesifikasjonsfilen hoppes over |
| - f.Kr | %pre- og %build-trinnene utføres. Dette vil pakke ut og kompilere pakken. |
| -bi | Stadiene %pre, %build, %install utføres |
| -bl | Listen over filer spesifisert i %files-makroen er sjekket |
| -bp | Bare %pre-stadiet utføres, det vil si at arkivet pakkes ut |
| --recompile package.src.rpm | Den spesifiserte pakken som inneholder kildene installeres først og kompileres deretter |
| --rebuild package.src.rpm | Installerer og kompilerer kildepakken, og lager deretter en ny binær pakke |
| --test | Sjekker spesifikasjonsfilen |
| --ren | Fjerning av BUILD-katalogtreet etter å ha opprettet en pakke |
| --showrc | Sender ut konfigurasjonsfilen |
Alle manualene jeg fant på Internett kommer i de fleste tilfeller ned til to typer:
— oversettelse av dokumentasjon (som jeg fortsatt anbefaler deg å lese, siden artikkelen min vil dekke bare deler av informasjonen du trenger i fremtiden)
— korte instruksjoner om hvordan du kjører rpmbuild når vi allerede har alt.
Personlig ble jeg møtt med behovet for å bygge en pakke fra en kilde, som det ikke var noe med, og viktigst av alt, en spesifikasjonsfil å bygge pakken fra. Som et resultat vil vi skrive vår egen spesifikasjonsfil for å bygge pakken og umiddelbart legge til våre egne konfigurasjoner der (dette problemet er heller ikke særlig godt dekket).
Jeg skal bygge en pakke fra ffmpeg-kildene for AirVideoServer, som jeg allerede har beskrevet som . Jeg er tilhenger av å installere applikasjoner gjennom den i en distribusjon som bruker en pakkebehandling, og det er grunnen til at jeg på CentOS ikke liker å bygge programvare fra kilden. Av denne grunn bestemte jeg meg for å samle alt i poser til meg selv. Å sette sammen den også nødvendige lame (den kommer med spesifikasjonsfiler inkludert) og x264 (du kan skrive en spesifikasjonsfil for det selv etter å ha lest denne artikkelen) bør ikke føre til problemer i fremtiden.
Og så, først må vi sette opp "miljøet" der vi skal samle pakken. Det anbefales ikke å bygge pakker fra under root, så vi vil opprette en egen bruker, men foreløpig vil vi installere all nødvendig programvare:
Yum installer gcc gcc-c++ automake autoconf libtool yasm nasm ncurses-devel git ftp rpmdevtools
La oss nå opprette en spesiell bruker
Brukerlegg til rpmbuild
og la oss gå under det
Su - rpmbuild
la oss utføre kommandoen
Rpmdev-oppsetttre
slik at den ville distribuere den nødvendige katalogstrukturen for oss å bygge
Og nå kan vi gå direkte til forsamlingen.
Vi trenger selve kilden
Wget http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2
brette det ut
Tar -xjf ffmpeg-for-2.4.5-beta7.tar.bz2
La oss legge konfigurasjonsfilen med innholdet ved siden av:
Nano airvideoserver.conf path.ffmpeg = /usr/bin/ffmpeg passord = subtitles.encoding = utf-8 subtitles.font = Verdana-mapper = Filmer:/home/share/films
La oss laste ned serverfilen her:
Wget http://inmethod.com/airvideo/download/linux/alpha6/AirVideoServerLinux.jar
Og init-skriptet:
Nano AirVideoServer #!/bin/bash #chkconfig: - 80 20 #beskrivelse: AirVideo-server # Kildefunksjonsbibliotek. . /etc/rc.d/init.d/functions PREFIX_DIR=/usr/local/AirVideo sak "$1" i start) echo -n "Starter AirVideo server: " daemon java -jar $(PREFIX_DIR)/AirVideoServerLinux.jar $( PREFIX_DIR)/properties.conf > /dev/null 2>&1 & [ $? -eq 0 ] && suksess || feil ekko ;; stop) echo -n "Stopper AirVideo-server: " killproc java echo ;; status) status java ;; start på nytt | last på nytt) $0 stopp ; $0 start ;; *) echo "Bruk: airvideo (start|stopp|status|reload|restart" exit 1 ;; esac
Nå kan vi gå videre til å skrive spesifikasjonsfilen vår for monteringen.
Først har vi de forskjellige overskriftene. Pakkenavnet, versjonen og utgivelsen er viktige de vil avgjøre hvilken katalog kilden skal distribueres til før montering. I Kilde1, Kilde2 og Kilde3 angir vi våre 3 tilleggsfiler, config, server og init-skript, som må legges til pakken når du bygger.
Navn: ffmpeg Versjon: 2.4.5 Utgivelse: beta7 Sammendrag: ffmpeg for AirVideoServer Lisens: GPL URL: http://inmethod.com/airvideo/ Kilde: http://inmethod.com/airvideo/download/ffmpeg-for-2.4 .5-beta7.tar.bz2 Kilde1: airvideoserver.conf Kilde2: AirVideoServer Kilde3: AirVideoServerLinux.jar BuildRoot: %(_tmppath)/%(name)-for-%(versjon)-%(release)
%description Verktøy og bibliotek for koding av H264/AVC-videostrømmer for AirVideoServer.
%prep-delen er ansvarlig for kommandoene som er nødvendige for å starte byggingen, slik at jeg ikke trenger å bekymre meg for å gi nytt navn til katalogen for formatet - jeg bruker bare -n-bryteren for å indikere hvor de utpakkede kildene er plassert
%prep %setup -n /home/rpmbuild/rpmbuild/BUILD/ffmpeg/
%build-delen er ansvarlig for å sette sammen kilden direkte. Du kan endre nøklene til de du trenger, som med vanlig montering og installasjon fra kilder:
%build ./configure \ --prefix="%(_prefix)" \ --bindir="%(_bindir)" \ --libdir="%(_libdir)" \ --enable-pthreads \ --disable-shared \ --enable-static \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame
%install-delen inneholder kommandoer for å installere pakkefiler på systemet her må vi i tillegg spesifisere hvor vi skal installere konfigurasjonsfilen, serveren og init-skriptet
%install %(__rm) -rf %(buildroot) %(__make) install DESTDIR="%(buildroot)" mkdir -p $RPM_BUILD_ROOT/usr/local mkdir -p $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE1) $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE2) $RPM_BUILD_ROOT/etc/init.d install -m 644 %(SOURCE3) $RPM_BUILD_ROOT/usr/local/AirVideo/
La oss rydde opp i søppelet og kjøre ldconfig
%clean %(__rm) -rf %(buildroot) %post -p /sbin/ldconfig %postun -p /sbin/ldconfig
Kommandoene i %files-delen spesifiserer lister over filer og kataloger som, med de riktige attributtene, skal kopieres fra byggetreet til rpm-pakken og deretter kopieres til målsystemet når denne pakken er installert.
%filer %defattr(-,root,root,-) %doc KOPIERING* KREDITTER LESMIG* %(_bindir)/avconv %(_bindir)/avprobe %(_bindir)/avserver %(_bindir)/ffmpeg /usr/include/* /usr/lib64/* /usr/share/avconv/* /usr/local/AirVideo/airvideoserver.conf /etc/init.d/AirVideoServer /usr/local/AirVideo/AirVideoServerLinux.jar
%doc-makroen markerer dokumentasjonsfiler, opphavsrettigheter og andre ting.
Med dette er spesifikasjonsfilen vår klar, nå må vi kjøre selve sammenstillingen
Rpmbuild -bb ffmpeg/ffmpeg.spec
Etter vellykket montering av pakken, etter fullføring, i katalogen RPMS/_architecture_/ vil vi ha vår pakke ffmpeg-2.4.5-beta7.x86_64.rpm som nå kan lastes opp og distribueres på hvilken som helst maskin.
Jeg håper denne lille håndboken vil hjelpe deg med å sette sammen dine egne pakker for installasjon, med dine egne konfigurasjonsfiler, som vil gjøre livet ditt enklere senere.
Det er to biler, identisk SLES versjon/bue.
Datamaskin #A har programvaren "foo" installert, som vi kan se ved å bruke rpm -qa .
Maskin #B må installere programvaren "foo".
foo.rpm er ikke tilgjengelig fra noen kilde, internett osv.
Spørsmål
Siden pakken foo.rpm ble installert på maskin #A, kan vi lage en foo.rpm-fil på den fra filene som allerede er installert?
Jeg tror det også er pre/post-skript i rpm. Så du kan installere foo.rpm ( med avhengigheter?).
2 Løsninger samler inn skjemanett for "Hvordan lage en RPM-pakke fra installerte filer?"
Det er mulig, men det er veldig vanskelig å få det gjort riktig. Hvis du er desperat, kan du opprette en ny RPM .spec-fil og lage en "falsk" kilde RPM-fil (SRPM), som du deretter kan bruke til å bygge den resulterende RPM-filen ved å bruke rpmbuild --rebuild .
Jeg ville fortsette å søke etter den faktiske RPM. Du spesifiserer ikke hva i spørsmålet ditt, men min erfaring er at du kan finne hva som helst på nettet hvis du vet hvordan du skal lete etter det. Jeg har funnet eldgamle versjoner av RPM-er for Red Hat-distribusjoner som ikke har vært brukt på over 10 år, så jeg ville ha vanskelig for å tro at det ikke er rester i denne RPM-en.
Du kan også ofte gå tilbake til applikasjonskilden som ligger i RPM og bruke den til å gjenopprette RPM. Ofte vil kildeapplikasjonene inneholde en nødvendig .spec-fil som brukes til å gjenopprette RPM.
Til slutt kan du hente kilden og .spec-filen fra en byggetjeneste, for eksempel for Koji-baserte distribusjoner for Red Hat. SuSE støtter lignende byggetjenester, slik at du kan søke etter dem for å få gamle byggeartefakter.
Tar binære filer som
Du kan bruke denne metoden til å løfte de faktiske kjørbare filene fra ett system og laste dem av for distribusjon til et annet system.
bil A
$ rpm -ql
bil B
$ tar -zxvf /path/to/ditt/program.tgz
RPM-versjon fra SLES
I følge et av innleggene i denne tråden: Re: Hvordan lage en RPM fra installerte rpm-pakker på SLES skal ha en --repackage-bryter. Dette eksisterer ikke i Red Hat-versjonen (på Fedora eller CentOS). Men ifølge innlegget kan du bruke det slik:
$ rpm -e --repackage
Etter det finner du RPM her:
/var/spool/ompakke
Bruker rpmerizor
Rpmerizor er et tredjepartsverktøy/skript som du kan installere som vil ompakke kildefilene til riktig RPM. Bruk av dette skriptet er tilgjengelig her, under navnet: rpmerizor man page.
utdrag
Rpmerizor er et skript som lar deg lage en RPM-pakke fra installerte filer. Du trenger bare å spesifisere filene på kommandolinjen og svare på noen interaktive spørsmål for å fylle ut rpm-metadata (pakkenavn, versjon...). Du kan også bruke den i batch-modus med kommandolinjealternativer for metadata.
Bruker rpmrebuild
For ikke å forveksle med byggeverktøyet rpmbuild, er rpmrebuild et annet tredjepartsskript som du kan bruke til å pakke om en allerede installert RPM.
utdrag
rpmrebuild er et verktøy for å lage en RPM-fil fra en pakke som allerede er installert i grunnleggende bruk, bruk av rpmrebuild krever ingen kunnskap om å lage en rpm. (På Debian er det tilsvarende produktet dpkg-repack).
eksempel
La oss si at vi ønsker å pakke om openssh-serveren.
$ rpm -aq | grep openssh-server openssh-server-6.2p2-8.fc19.x86_64
Nå er pakken:
$ rpmrebuild openssh-server-6.2p2-8.fc19.x86_64 /usr/lib/rpmrebuild/rpmrebuild.sh: ADVARSEL: noen filer har blitt endret: ..?...... c /etc/ssh/sshd_config . .?...... c /etc/sysconfig/sshd Vil du fortsette? (y/N) y Vil du endre utgivelsesnummer? (y/N) n resultat: /root/rpmbuild/RPMS/x86_64/openssh-server-6.2p2-8.fc19.x86_64.rpm
- Re: Hvordan lage RPM-installerte pakker
Som regel nei.
Med litt rpm -qi og rpm -q gir --changelog en ide om hvor pakken kom fra.
Hvis den ble bygget på systemet den kjører på, kan du fortsatt bruke spesifikasjonsfilen som brukes til å generere de faktiske turtallet, hvis ikke begge deler.
rpm -q --list
rpm -q --scripts
Og alle avhengigheter som må installeres kan bli funnet ved å bruke rpm -q --requires