Product SiteDocumentation Site

Kapittel 15. Å lage en Debian-pakke

15.1. Å bygge om en pakke fra sine kilder
15.1.1. Å skaffe kildene
15.1.2. Å lage forandringer
15.1.3. Å starte gjenoppbyggingen
15.2. Å bygge din første pakke
15.2.1. Meta-pakker eller falsk pakker
15.2.2. Et enkelt filarkiv
15.3. Å lage en pakkebrønn for APT
15.4. Å bli en pakkevedlikeholder
15.4.1. Å lære å lage pakker
15.4.2. Aksepteringsprosess
Det er nokså vanlig for en administrator som har håndtert Debian-pakker jevnlig å etter hvert ønske å lage egne pakker, eller modifisere en eksisterende pakke. Dette kapittelet tar sikte på å svare på de vanligste spørsmålene på dette området, og gi nødvendige instrukser for å utnytte Debians infrastruktur på beste måte. Med litt flaks, etter å ha prøvd deg fram med lokale pakker, kan du kanskje til og med tenke deg å gå lengre, og bli med i Debian-prosjektet selv!

15.1. Å bygge om en pakke fra sine kilder

Å bygge om en binær pakke er nødvendig under flere omstendigheter. I noen tilfeller trenger administratoren en programvarefunksjon som krever at programvaren som skal kompileres fra kilder med et spesielt kompileringsalternativ; i andre er programvaren som er pakket i den installerte versjonen av Debian ikke ny nok. I det sistnevnte tilfellet vil administratoren vanligvis bygge en nyere pakke tatt fra en nyere versjon av Debian - så som Testing, eller til og med Unstable - slik at denne nye pakken virker i deres Stable-distribusjon: Denne operasjonen kalles «backporting». Som vanlig bør man være forsiktig før en tar på seg en slik oppgave, men sjekke om den har blitt gjort allerede: Ta en rask titt på Debian Package Tracker for å se om pakken kan vise informasjon om det.

15.1.1. Å skaffe kildene

Å bygge om en Debian-pakke starter med å skaffe seg kildekoden. Den enkleste måten er å bruke apt-get source kildepakkenavn-kommandoen. Denne kommanoen krever en deb-src-linje i /etc/apt/sources.list-filen, og oppdaterte indeksfiler (det er apt-get update). Disse betingelsene skulle allerede være imøtekommet hvis du fulgte instruksjonene fra kapittelet om APT-konfigurasjon (se Seksjon 6.1, «Å fylle inn sources.list-filen»). Merk imidlertid at du vil laste ned kildekodepakkene fra den Debian-versjonen som er nevnt i deb-src-linjen. Hvis du trenger en annen versjon, må du kanskje laste den ned manuelt fra et Debian-speil, eller fra nettstedet. Dette innebærer henting av to eller tre filer (med utvidelser *.dsc - for Debian Source Control - *.tar.comp, og noen ganger *.diff.gz eller *.debian.tar.comp - comp som tar en verdi blant gz, bz2 eller xz, avhengig av det kompresjonsverktøyet som er i bruk), så kjør dpkg-source -x file.dsc-kommandoen. Hvis *.dsc-filen er tilgjengelig direkte fra en gitt URL, er det til og med enklere vei å få tak i alt sammen, med dget URL-kommandoen. Denne kommandoen (som kan bli funnet i devscripts-pakken) fanger opp *.dsc-filen på den gitte adressen, så analyserer den innholdet, og filen eller filene det refereres til hentes automatisk. Når alt er lastet ned, pakkes kildepakken ut (såfremt -d eller --download-only-valget er benyttet).

15.1.2. Å lage forandringer

Pakkekilden er tilgjengelig i en katalog oppkalt etter kildepakkens versjon (for eksempel samba-4.1.17+dfsg): Dette er der vi skal jobbe med våre lokale endringer.
Det første du må gjøre er å endre pakkens versjonsnummer, slik at de gjenoppbygde pakkene kan skilles fra de opprinnelige pakkene som følger med Debian. Forutsatt at gjeldende versjon er 2:4.1.17+dfsg-2, kan vi lage versjon 2:4.1.17+dfsg-2falcot1, som tydelig viser opprinnelsen av pakken. Dette gjør pakkens versjonsnummer høyere enn den som tilbys av Debian, slik at pakken lett vil installeres som en oppdatering til den opprinnelige pakken. En slik endring er best utført med dch-kommandoen (Debian CHangelog) fra devscripts-pakken med en kommando slik som dch --local falcot. Dette tar i bruk en tekstrediger (sensible-editor - dette burde være din favorittredigerer hvis den er nevnt i VISUAL, eller EDITOR-miljøvariablene, og ellers standardredigereren) for å tillate å dokumentere forskjellene som følger av denne ombyggingen. Denne redigereren viser oss at dch virkelig forandret debian/changelog-filen.
Når det kreves en endring i oppbyggingen, må det lages endringer i debian/rules, som skritt for skritt driver pakkens byggeprosess. I de enkleste tilfellene er linjene om den opprinnelige konfigurasjonen (./configure …), eller i den aktuelle utgaven ($(MAKE) …, eller make …) enkle å finne. Hvis disse kommandoene ikke påkalles eksplisitt, er de sannsynligvis en bivirkning av en annen eksplisitt kommando, i så fall kan du se i dokumentasjonen for å lære mer om hvordan du endrer standard virkemåten. Med pakker som bruker dh, kan du trenge å legge til en overstyring for dh_auto_configure, eller dh_auto_build-kommandoene (se de respektive manualsidene deres for forklaringer om hvordan du oppnår dette).
Avhengig av de lokale endringene i pakkene, kan en oppdatering også være nødvendig i debian/control-filen, som inneholder en beskrivelse av de genererte pakker. Spesielt inneholder denne filen Build-Depends-linjer som kontrollerer listen over avhengigheter som må være oppfylt når pakken bygges. Disse refererer ofte til versjonene til pakkene i distribusjonen som kildepakken kommer fra, men som kanskje ikke er tilgjengelig i distribusjonen som brukes til ombygging. Det er ingen automatisk måte å avgjøre om en avhengighet er ekte, eller bare spesifisert til å garantere at bygget kun skal bli forsøkt med den nyeste versjonen av et bibliotek - dette er den eneste tilgjengelige måten å tvinge en autobuilder til å bruke en gitt pakkeversjon under oppbyggingen, og det er derfor Debians vedlikeholdere ofte bruker strenge versjonsbestemte byggeavhengigheter.
Hvis du vet sikkert at disse byggeavhengigheter er for strenge, bør du føle deg fri til å løsne på dem lokalt. Å lese filene som dokumenterer den vanlige måten å bygge programvare på - disse filene blir ofte kalt INSTALL - vil hjelpe deg å finne de riktige avhengighetene. Ideelt sett bør alle avhengigheter være imøtekommet fra distribusjonen som brukes til ombygging. Hvis de ikke er det, starter en gjentakingsprosess, der pakkene nevnt i Build-Depends-feltet må «backportes» («tilbakeporting») før målet pakken kan bli det. Noen pakker trenger kanskje ikke tilbakeporting, og kan installeres som de er i løpet av byggeprosessen (et kjent eksempel er debhelper). Merk at tilbakeportingsprosessen raskt kan bli komplisert hvis du ikke er forsiktig. Derfor bør tilbakeporting holdes på et absolutt minimum der det er mulig.

15.1.3. Å starte gjenoppbyggingen

Når alle de nødvendige endringene har blitt brukt på kildene, kan vi starte å generere den aktuelle binære pakkefilen (.deb). Hele prosessen er håndtert av dpkg-buildpackage-kommandoen.

Eksempel 15.1. Å bygge om en pakke

$ dpkg-buildpackage -us -uc
[...]
Den tidligere kommandoen kan mislykkes hvis Build-Depends-feltene ikke har blitt oppdatert, eller hvis de relaterte pakker ikke er installert. I dette tilfellet er det mulig å overprøve denne sjekken ved å sende -d-valget til dpkg-buildpackage. Men å eksplisitt ignorere disse avhengigheter gir risiko for at byggeprosessen mislykkes på et senere tidspunkt. Verre; pakken kan synes å bli bygget riktig, men klarer ikke å kjøre skikkelig: Noen programmer deaktiverer automatisk noen av sine oppgaver når et nødvendig bibliotek ikke er tilgjengelig på byggetidspunktet.
I de fleste tilfeller bruker Debian-utviklere et høynivå-program som debuild. Dette kjører dpkg-buildpackage til vanlig, men legger også til en påkalling til et program som kjører mange kontroller for å validere den genererte pakken opp mot Debians retningslinjer. Dette skriptet renser også opp i miljøet, slik at lokale miljøvariabler ikke «forurenser» pakkebyggingen. Kommandoen debuild er et av verktøyene i devscripts-pakken, som deler noe konsistens og oppsett for å gjøre vedlikeholderens oppgave enklere.