Kapittel 15. Hvordan lage en Debian-pakke

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 har som mål å 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 selv bli med i Debian-prosjektet!

15.1. Ombygging av pakke fra kildekoden

Å bygge en binær pakke på nytt er nødvendig under flere omstendigheter. I noen tilfeller trenger administratoren en programvarefunksjon som krever at programvaren som skal kompileres fra kildekoden 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 «tilbakeføring». Som vanlig bør man være forsiktig før en tar på seg en slik oppgave, og først sjekke om den har blitt gjort allerede: Ta en rask titt på Debians pakkesporer for å sjekke om pakken kan vise info om det.

→ https://tracker.debian.org/

15.1.1. Henting av kildekode

Å gjenoppbygge en Debian-pakke starter med å hente kildekoden. Den enkleste måten er å bruke kommandoen apt-get source pakkenavn. Slik bruk krever en deb-src-linje i filen /etc/apt/sources.list, og en oppdatert oversikt over pakkebrønnsfiler (for eksempel ved bruk av apt-get update). Disse forutsetningene bør allerede være på plass hvis du har fulgt instruksen i kapitlet som har med APT-oppsett å gjøre (sjekk Seksjon 6.1, «Innfylling av sources.list-filen»). Merk at du laster ned kildepakkene fra Debian-versjonen nevnt ideb-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 kompresjonsverktøyet som ble bruk), kjør deretter 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 er en del av pakke devscripts) 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, verifiseres integriteten til den nedlastede kildekoden ved å bruke dscverify, og det pakker ut kildekoden (om ikke -d eller --download-only-valget er benyttet). Debian nøkkelring behøves om ikke valget -u foreligger.

15.1.2. Hvordan gjøre endringer

La oss bruke samba-pakken som et eksempel.

$ apt source samba
Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 12.3 MB of source archives.
Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B]
Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB]
Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB]
Fetched 12.3 MB in 3s (4,582 kB/s)
dpkg-source: info: extracting samba in samba-4.13.13+dfsg
dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
dpkg-source: info: applying [...]

Pakkekilden er tilgjengelig i en katalog oppkalt etter kildepakkens versjon (samba-4.13.13+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 nye pakkene kan skilles fra de opprinnelige pakkene som følger med Debian. Forutsatt at gjeldende versjon er 2:4.13.13+dfsg-1~deb11u3, kan vi lage versjon 2:4.13.13+dfsg-1~deb11u3falcot1, 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.

$ cd 4.13.13+dfsg-1~deb11u3
$ dch --local +falcot

Den siste kommandoen kaller et tekstredigeringsprogram (sensible-editor — dette bør være ditt favoritt-tekstredigeringsprogram hvis det er nevnt i VISUAL eller EDITOR-miljøvariablene, og forvalgt tekstredigeringsprogram ellers) for å tillate dokumentering av forskjellene som er forårsaket av denne gjenoppbyggingen. Dette skriveprogrammet viser oss at dch virkelig har endret 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 det opprinnelige oppsettet (./configure …), eller i det aktuelle bygget ($(MAKE) …, eller make … eller cmake … eller …) 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 forvalgt virkemåte. For pakker som bruker dh kan du trenge å legge til en overstyring for dh_auto_configure, eller dh_auto_build-kommandoene (sjekk de respektive manualsidene deres og debhelper(7) for forklaringer på 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, står du fritt til å gjøre dem mindre strenge 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å «tilbakeføres» før pakken som er målet for operasjonen kan bli det. Noen pakker trenger kanskje ikke tilbakeføring, og kan installeres som de er i løpet av byggeprosessen (et kjent eksempel er debhelper). Merk at tilbakeføringsprosessen raskt kan bli komplisert hvis du ikke er forsiktig. Derfor bør tilbakeføring 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
[...]

Forrige kommando kan mislykkes hvis Build-Depends-feltet ikke har blitt oppdatert, eller hvis de relaterte pakkene ikke er installert. I dette tilfellet er det mulig å overprøve denne sjekken ved å sende -d-argumentet til dpkg-buildpackage. Men å eksplisitt ignorere disse avhengigheter gir risiko for at byggeprosessen mislykkes på et senere tidspunkt. Verre; pakken kan se ut til å bygges korrekt, men klarer ikke å kjøre skikkelig: Noen programmer deaktiverer automatisk noen av sine egenskaper når et nødvendig bibliotek ikke er tilgjengelig på byggetidspunktet. Argumentet kan fremdeles være nyttig hvis du kun vil opprette en kildepakke, som er ment å sendes til et rene byggmiljø, som beskrevet i RASK TITT Bygging av pakker i chrooted og virtuelle omgivelser.

De andre valgene i eksempelet ovenfor sørger for at hverken kildepakkens .dsc (-us) og ei heller resulterende .changes-fil (-uc) signeres med pakkebyggerens kryptografiske nøkkel etter at bygget fullføres på riktig vis.

VERKTØY fakeroot

I hovedsak er prosessen med å bygge pakker en så enkel sak som, i et arkiv, å samle et sett av eksisterende (eller bygde) filer. De fleste filene vil så bli eid av rot i arkivet. Men å bygge hele pakken under denne brukeren skulle tilsi økt risiko. Heldigvis kan dette unngås med fakeroot-kommandoen. Dette verktøyet kan brukes til å kjøre et program, og gi inntrykk av at det kjører som root, og skaper filer med vilkårlig eierskap og rettigheter. Når programmet skaper arkivet som vil bli Debian-pakken, er det lurt å skape et arkiv som inneholder filer merket som tilhørende vilkårlige eiere, inkludert rot. Dette oppsettet er så praktisk at dpkg-buildpackage bruker fakeroot som standard ved pakkebygging.

Merk at programmet bare er lurt til å «tro» at det fungerer som en priviligert konto, og prosessen faktisk kjører som om brukeren kjører fakeroot program (og filene faktisk er opprettet med den brukerens tillatelser). Ikke på noe tidspunkt får det faktisk rotprivilegier som det kunne misbruke.

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.

RASK TITT Bygging av pakker i chrooted og virtuelle omgivelser

Å bygge en pakke på et eksisterende system som for eksempel en arbeidsstasjon eller tjener, kan by på problemer. Kanskje har systemet pakker installert som krangler med bygg-kravene. Eller kanskje det har pakker (biblioteker, hoder, og så videre) installert, som prosjektet som skal bygges ikke er ment å bruke, for eksempel fra Testing, Ustabil, eller til og med noe fra tredjeparter. Det kan også hende systemet har pakker installert som faktisk kreves for byggingen, men ikke er listet opp i debian/control. Det er derfor god praksis å bygge pakker i et «rent» miljø.

Programmene sbuild, pbuilder, eller cowbuilder (i pakkene med tilsvarende navn) tillater bygging av en Debian-pakke i en chroot-omgivelse. Hver av dem lager først en midlertidig katalog med det minimale systemet som kreves for å bygge pakken (inkludert pakkene nevnt i Build-Depends-feltet). Denne katalogen blir så brukt som rotkatalog (/), og bruker chroot-kommandoen under byggeprosessen.

Disse verktøyene gjør at byggeprosessen skjer i et miljø som ikke påvirkes av det brukerne gjør. Dette gir også mulighet for å rask oppdage manglende byggeavhengigheter (i og med at byggingen vil feile med mindre de korrekte avhengighetene er ført opp). Og ikke minst, så kan en bygge en pakke for en Debian-versjon som ikke er den som brukes av systemet som helhet. Maskinen kan bruke Stable i sitt normale arbeid, og sine chroot-omgivelser som kjører på den samme maskinen, kan bruke Unstable til pakkebygging. Ved å bruke disse verktøyene blir det også mulig å bygge for en annen distribusjon, som Ubuntu.

schroot, sbuild-shell, eller pbuilder tillater kjøring av en kommando eller et innloggingsskall i et chroot-et miljø.

Noen ganger er det ikke nok å bygge en pakke i en chroot-omgivelse. Dette kan være fordi en bygger en annen arkitektur der kryss-kompilering ikke virker, eller som følge av at verktøyene ikke er i stand til å opprette chroot-omgivelse for ønsket målsystem. Da kan man i stedet opprette virtuelle maskiner for å bygge pakken der. Disse oppsettene er vanligvis mer komplekse enn bruk av verktøyene nevnt over, og sjeldent nødvendig. Denne muligheten nevnes uten å gå i detalj. Sjekk Seksjon 12.2, «Virtualisering» for en introduksjon i emnet.