Product SiteDocumentation Site

15.4. Å bli en pakkevedlikeholder

15.4.1. Å lære å lage pakker

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. Regler

En Debian-pakke må være i samsvar med de presise regler utarbeidet i Debians retningslinjer, og hver pakkeutvikler må kjenne til dem. Det er ingen krav om å kjenne dem utenat, men heller å vite at de eksisterer, og referere til dem når et valg presenterer et ikke-trivielt alternativ. Hver Debian-vedlikeholder har gjort feil ved å ikke kjenne til en regel, men det er ikke et stort problem, så lenge feilen blir fikset når en bruker rapporterer den som en feilrapport (som pleier å skje ganske snart, takket være avanserte brukere). Standards-Version-feltet i debian/control spesifiserer versjonen av Debian-policyen som en pakke samsvarer med. Vedlikeholdere bør overholde den siste versjonen av Debian-policyen.

15.4.1.2. Prosedyrer

Debian er ikke en enkel samling av enkeltpakker. Alles pakkearbeid er en del av et kollektivt prosjekt; å være en Debian-utvikler innebærer å vite hvordan Debian-prosjektet fungerer som en helhet. Hver utbygger vil, før eller senere, samhandle med andre. Debians utviklerreferanse (Debian Developer's Reference) (i developers-reference-package) oppsummerer hva alle utviklere må vite for å samhandle så smidig som mulig med de ulike teamene i prosjektet, og for å få mest mulig ut av de tilgjengelige ressursene. Dette dokumentet oppsummerer også en rekke oppgaver en utvikler forventes å oppfylle.

15.4.1.3. Verktøy

Mange verktøy hjelper pakkevedlikeholdere med deres arbeid. Denne seksjonen gir en rask gjennomgang, uten alle detaljene, ettersom verktøyene har sin egen omfattende dokumentasjon.
15.4.1.3.1. devscripts
Pakken devscripts inneholder mange programmer som hjelper til på et stort område i Debian-utviklerens jobb:
  • debuild tillater å generere en pakke (med dpkg-buildpackage), og kjøre lintian for så å sjekke overensstemmelsen med Debians retningslinjer.
  • debclean renser en kildepakke etter at en binærpakke har blitt generert.
  • dch tillater en rask og enkel redigering av en debian/changelog-fil i en kildepakke.
  • uscan sjekker om en ny programvareversjon er utgitt av oppstrømsforfatteren; dette krever en debian/watch-fil med beskrivelse av plasseringen av slike utgivelser.
  • debi tillater installering (med dpkg -i) av Debian-pakken som nettopp ble generert, uten å måtte skrive inn dens fulle navn og sti.
  • På lignende måte tillater debc skanning av innholdet i den nylig generert pakken (med dpkg -c), uten å måtte skrive inn dens fulle navn og sti.
  • bts styrer feilrapporteringssystemet fra kommandolinjen; dette programmet genererer automatisk de riktige e-postene.
  • debrelease laster opp en nylig generert pakke til en ekstern tjener, uten å måtte skrive hele navnet og banen til den relaterte .changes-filen.
  • debsign signerer *.dsc og *.changes-filene.
  • uupdate automatiserer opprettelsen av ny revisjon av en pakke når en ny oppstrømsversjon er utgitt.
Alle de nevnte kommandoene er dokumentert på respektive manualsider. De kan videre settes opp per bruker i én fil: ~/.devscripts.
15.4.1.3.2. debhelper og dh-make
Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).
Skriptet dh_make (i dh-make-pakken) lager filer som kreves for å generere en Debian-pakke i en katalog som i utgangspunktet inneholder kildene for et stykke programvare. Som det kan gjettes fra navnet på programmet, bruker de genererte filene debhelper som standard.
15.4.1.3.3. lintian
Dette verktøyet er et av de viktigste: Det er Debian-pakkesjekkeren. Den bygger på et stort utvalg av tester opprettet fra Debians retningslinjer, og oppdager raskt og automatisk mange feil som deretter kan rettes før pakkene utgis.
Dette verktøyet er bare en hjelper, og noen ganger gjør den feil (for eksempel, siden Debians retningslinjer endrer seg over tid, blir lintian noen ganger utdatert). Det er heller ikke uttømmende: Selv om du ikke får noen Lintian-feilmelding, bør dette ikke tolkes som et bevis på at pakken er perfekt; i beste fall unngås de vanligste feilene.
15.4.1.3.4. piuparts
Dette er et annet viktig redskap: Det automatiserer installasjonen, oppgraderer, fjerner og renser en pakke (i et isolert miljø), og kontrollerer at ingen av disse operasjonene fører til feil. Det kan hjelpe til med å avdekke manglende avhengigheter, og det oppdager også når filer feilaktig er til overs etter at pakken er renset.
15.4.1.3.5. autopkgtest
autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.
15.4.1.3.6. reprotest
reprotest bygger samme kildekode to ganger i forskjellige miljøer, og kontrollerer deretter binærfilene som produseres av hver oppbygning for forskjeller. Hvis noen blir funnet, brukes diffoskop (hvis det ikke er tilgjengelig, diff) for å vise dem i detalj for senere analyse.
15.4.1.3.7. dupload og dput
The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.
15.4.1.3.8. git-buildpackage og dgit
Prosjektet har brukt forskjellige versjonkontrollsystemer i årenes løp for å lagre pakkingstiltak, eller pakke-kildekode, eller for å tillate samarbeid om pakkevedlikehold. For å forene systemene og tiltakene ble det i 2017 besluttet å flytte (nesten) alle pakkekilder inn i Git (KULTUR Git) til en GitLab-instans som heter\t salsa.debian.org.
For å gjøre pakking enklere ved bruk av Git for Debian-utviklerne har det blitt utviklet noen verktøy. Disse tillater ikke bare lagring av pakkingsfiler i Git, men også å bruke Git-kodelager (og historikken deres) til programvareprosjekter, legge til feilfikser for pakkekilder i Git-historikken, vedlikeholde versjoner per distribusjon, osv.
En av de mest kjente pakkene er git-buildpackage. Et alternativ er dgit. Selvfølgelig er det fremdeles mulig å ikke bruke noen av dem.
Nedenfor finner du et eksempel for ~/.gbp.conf-oppsettsfilen
[DEFAULT]
builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL"
pristine-tar = true

[buildpackage]
sign-tags = true
keyid = XXXX
postbuild  = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64 
export-dir = /tmp/build-area/
notify = off

[import-orig]
filter-pristine-tar = true
sign-tags = true

[pq]
drop = true
Bygging av pakken kan så gjøres ved å kjøre gbp buildpackage i Git-treet. Det starter bygging av en pakke i en Debian Bullseye-chroot ved bruk av sbuild. Når bygget fullføres på riktig vis vil de opprettede filene bli sjekket med utvalget av autopkgtest-programmer (hvis definert). Alle de forskjellige alternativene er forklart i gbp.conf(5) og /etc/git-buildpackage/gbp.conf.
Alle verktøyene som har blitt nevnt så langt er inkludert i den kontinuerlige integrasjonsprosessen (CI) på salsa.debian.org-instansen også:

15.4.2. Aksepteringsprosess

Å bli en «Debian-utvikler» er ikke en enkel administrativ sak. Fremgangsmåten omfatter flere trinn, og er like mye en igangsetting som det er utvelgelsesprosess. I alle fall er det formalisert og godt dokumentert, slik at alle kan spore sin progresjon på nettsiden dedikert til prosessen for det nye medlemmet.

15.4.2.1. Forutsetninger

Alle kandidater forventes å ha i det minste arbeidskunnskap om det engelske språket. Dette er nødvendig på alle nivåer: for den første kommunikasjon med den som gjennomgår, selvfølgelig, men også senere, siden engelsk er det foretrukne språket for det meste av dokumentasjonen. I tillegg vil pakkebrukerne kommunisere på engelsk ved innrapportering av feil, og de vil forvente svar på engelsk.
Den andre forutsetningen omhandler motivasjon. Å bli en Debian-utvikler er en prosess som bare gir mening dersom kandidaten vet at interessen for Debian vil vare i mange måneder. Aksepteringsprosessen kan i seg selv vare flere måneder, og Debian trenger langtidsutviklere. Hver pakke trenger permanent vedlikehold, og ikke bare en første opplasting.

15.4.2.2. Registrering

Det første (virkelige) trinnet består i å finne en sponsor eller talsperson. Det betyr en offisiell utvikler som er villig til å si at de tror at å akseptere, X vil bli en god ting for Debian. Dette innebærer vanligvis at kandidaten allerede har vært aktiv i fellesskapet, og at arbeidet har blitt verdsatt. Dersom kandidaten er sjenert, og arbeidet ikke er offentlig kjent, kan de prøve å overbevise en Debian-utvikler til å argumentere for dem ved å vise deres arbeid i fortrolighet.
Samtidig må kandidaten generere et offentlig/privat RSA-nøkkelpar med GnuPG, som skal være underskrevet av minst to offisielle Debian-utviklere. Signaturen godkjenner navnet på nøkkelen. Under et nøkkelsigneringsselskap må faktisk hver deltaker vise en offisiell identifikasjon (vanligvis et ID-kort eller pass) sammen med sine nøkkelidentifiseringer. Dette trinnet bekrefter sammenhengen mellom mennesker og nøklene. Denne signaturen krever dermed at en møtes i det virkelige liv. Hvis du ennå ikke har møtt noen Debian-utviklere på en offentlig fri programvarekonferanse, kan du eksplisitt søke utviklere som bor i nærheten ved hjelp av en liste på følgende nettside som utgangspunkt.
Så snart registeringen på nm.debian.org er blitt validert av en talsperson, blir en programleder (Application Manager) tildelt kandidaten. Søknadsbehandleren vil så kjøre prosessen gjennom flere forhåndsdefinerte trinn og sjekker.
Den første bekreftelsen er en identitetssjekk. Hvis du allerede har en nøkkel signert av to Debian-utviklere, er dette trinnet lett; ellers vil søknadsbehandleren prøve å veilede deg i ditt søk etter Debian-utviklere i nærheten, for å organisere et møte og en nøkkelsignering.

15.4.2.3. Å akseptere prinsippene

Disse administrative formaliteter følges ut fra filosofiske betraktninger. Poenget er å sørge for at kandidaten forstår og aksepterer den sosiale kontrakten og prinsippene bak fri programvare. Å bli med i Debian er bare mulig hvis man deler de verdier som forener dagens utviklere, som uttrykt i de grunnleggende tekster (og oppsummert i Kapittel 1, Debian-prosjektet).
I tillegg skal hver kandidat som ønsker å bli med i Debians rekker forventes å kjenne arbeidet i prosjektet, og hvordan de skal samhandle på riktig måte for å løse de problemene de vil utvilsomt vil møte under tiden. All denne informasjonen er vanligvis dokumentert i manualer rettet mot de nye vedlikeholderne, og i Debian-utviklerreferanse. En oppmerksom lesing av dette dokumentet bør være nok til å svare på eksaminators spørsmål. Hvis svarene ikke er tilfredsstillende, vil kandidaten bli informert. De vil da måtte lese (igjen) den relevante dokumentasjonen før de prøver igjen. I de tilfeller hvor den eksisterende dokumentasjonen ikke inneholder riktig svar på spørsmålet, kan kandidaten vanligvis komme med et svar fra litt praktisk erfaring innen Debian, eller potensielt ved å diskutere med andre Debian-utviklere. Denne mekanismen sikrer at kandidatene blir noe involvert i Debian, før de blir en full del av det. Dette er en bevisst politikk, der kandidatene som til slutt blir med i prosjektet, er integrert som en del av et uendelig utvidbart puslespill.
Dette trinnet er vanligvis kjent som Filosofi & Prosedyrer (P& P i kortform) i språket til utviklerne som er involvert i nye medlemmer-prosessen.

15.4.2.4. Å sjekke ferdigheter

Hver søknad om å bli en offisiell Debian-utvikler må begrunnes. Å bli en prosjektdeltaker krever at en viser at denne statusen er legitim, og at den letter kandidatens jobb med å hjelpe Debian. Den vanligste begrunnelsen er at å ha fått Debian-utviklerstatus, letter vedlikehold av en Debian-pakke, men det er ikke den eneste. Noen utviklere deltar i prosjektet for å bidra til portering til en bestemt arkitektur, andre ønsker å forbedre dokumentasjon, og så videre.
Dette trinnet representerer muligheten for kandidaten til å si ifra om hva de har tenkt å gjøre i Debian-prosjektet, og for å vise hva de allerede har gjort for dette formålet. Debian er et pragmatisk prosjekt, og å si noe er ikke nok hvis handlinger ikke samsvarer med hva som er annonsert. Vanligvis, når den tiltenkte rolle i prosjektet er knyttet til pakkevedlikehold, må en første versjon av den potensielle pakken være godkjent teknisk, og lastet opp til Debian-tjenere med en sponsor blant de eksisterende Debian-utviklerne.
Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.
Dette skrittet er kjent som Oppgaver & Ferdigheter trinnet (forkortet til: T&S) i eksaminators språkbruk.

15.4.2.5. Endelig godkjenning

I det aller siste trinnet blir hele prosessen gjennomgått av en DAM (Debians kontoadministratorer). DAM vil gjennomgå all informasjon om kandidaten som sensor har samlet inn, og gjør vedtak hvorvidt det skal opprettes en konto på Debian-tjenerne. I tilfeller der ekstra informasjon er nødvendig, kan det å opprette en konto bli forsinket. Avslag er ganske sjeldne hvis eksaminator gjør en god jobb med å følge prosessen, men kan skje noen ganger. De er aldri permanente, og kandidaten står fritt til å prøve igjen på et senere tidspunkt.
DAMs avgjørelse er autoritativ og (nesten) uten ankemuligheter, noe som forklarer hvorfor folk i denne posisjonen ofte har blitt kritisert i det siste.