Intervju: Aaron Griffin
Mannen bak Arch Linux
Arch Linux er en av de mer populære KISS-distribusjonene der ute. Vi har snakket med sjefen selv.
Intervju - Del 2
Etter hva vi forstår ble pacman skrevet spesifikt for Arch. Hvorfor lage deres egen pakkebehandler?
Pakkebehandling
Makepkg er et verktøy som benytter seg av informasjon lagret i en PKGBUILD-fil for å lage pakker for Arch. Disse pakkene kan så bli installert med pacman.
ABS er et verktøy for å laste ned PKGBUILDs for pakker i de offisielle pakkebrønnene, som tillater brukere å kompilere sine egne pakker fra kildekoden med makepkg.
PKGBUILDs er tekst filer som inneholder nødvendig informasjon for å kompilere programvare fra kildekode. Informasjonen inkluderer hvor kildekoden kan lastes ned, innstillinger for kompilering, hvilken arkitektur programvaren skal kompileres for, hvilken lisens som er i bruk... Hvem som helst kan lage en PKGBUILD, og hvis du vil dele denne med dine medbrukere kan du laste filen opp til AUR (Arch User Repository).
Pacman kom til verden fordi, alt annet var bare for komplekst. Andre løsninger trengte gjerne syv verktøy og hadde et komplekst pakkeformat. Pacman var et forsøk på å lage noe enkelt og oversiktlig, noe jeg mener vi har lyktes med.
AUR lar hvem som helst laste opp sine egne PKGBUILDs slik at andre kan laste de ned. Når kom ideen om AUR på bordet?
AUR kom til verden for lenge siden. Opprinnelig ble det kalt TUR eller Trusted-User Repository, hvor vi hadde en gruppe mennesker som hver hadde sin pakkebrønn som ble støttet offisielt av Arch. Det var egentlig ikke noe web-basert grensesnitt eller noe slikt før vi begynte å diskutere muligheten for å kombinere disse pakkebrønnene i en sentral pakkebrønn, [community].
AUR er nå i full utvikling og det er vanligvis mye aktivitet på vår aur-dev mailing list, hvor folk helper til med å forbedre AURs grensesnitt og den generelle AUR opplevelsen.
Klikk for større bilde
Ved bruk av AUR og et alternativt brukersnitt til pacman som f.eks. yaourt, får du muligheten til å installere programvare på en enkel måte selv om de ikke er offisielt støttet av Arch. Hvorfor har ikke pacman muligheten for å kompilere programvare fra AUR? Eller hvorfor legges ikke pakker som yaourt til de offisielle pakkebrønnene?
Arch User Repository
AUR er egentlig to pakkebrønner hvor brukerne selv bestemmer innholdet. I [unsupported] pakkebrønnen, kan hvem som helst laste opp sin PKGBUILD fil. Brukere kan deretter finne og laste ned denne PKGBUILDen gjennom AURs web-baserte brukersnitt og kompilere den ved bruk av makepkg. Hvis de liker PKGBUILD fila kan de stemme for at pakken skal inkluderes i [community] pakkebrønnen.
[community] inneholder binære pakker som kan installeres i gjennom pacman. På grunn av dette, vil ikke [community] inneholde pakker som går imot Archs retningslinjer. Pakkebrønnen er opprettholdt av en gruppe tillitsvalgte brukere (Trusted Users eller TUs som nevnt tidligere). Dette er gjerne mennesker som har lastet opp mange PKGBUILD filer til [unsupported] tidligere, og som andre stoler på kan kompilere pakker som ikke ødelegger deres Arch maskin.
For det første så vil pacman aldri kompilere programvare fra kildekode. Det er rett og slett ikke pacmans oppgave. Å inkludere den muligheten hadde vært som å gi cp - kommando for å kopiere filer - muligheten til å vise innholdet i en mappe. Det har ingenting for seg. For å nevne litt Unix-filosofi: ett verktøy for jobben.
For det andre så er det for mange sikkerhets-risikoer med verktøy som automatisk kompilerer programvare på denne måten. Dette betyr ikke at vi anser våre brukere som dumme. Vi tror på at hvis du har lyst å ta den risikoen, så skal du for all del gjøre det. Men, det skal være en liten hindring å passere for å ta de risikoene. En skal ikke kunne skru på automatisk installasjon fra [unsupported] ved et uhell.
Å ha verktøy som tillater slik automatisk installasjon i de offisielle pakkebrønnene, er det samme som at vi nikker hodet til alle PKGBUILD-filer i [unsupported]. Det er som at vi i kjerne-teamet sier "For all del, gjør det. Det er greit". Problemet er, det er ikke greit. Det er en sikkerhets-risiko som alle skal være oppmerksom på.
Hvordan er pakkebrønnene satt opp, og hva er restriksjonene på de ulike?
[core] pakkebrønnen inneholder "kjernen av Arch Linux". Det betyr, at det inneholder alle pakkene som MÅ være perfekt for at distribusjonen fortsetter å fungere. Dette er de absolutt system-kritiske pakkene. Vi er veldig kritiske angående hvilke pakker som ender opp i [core].
[extra] derimot, er veldig anderledes. [extra] inneholder alle pakkene vi føler et operativsystem bør støtte, men som igjen ikke er system-kritiske. Selvfølgelig, enkelte av disse pakkene, som apache, kan være viktige for enkelte brukere, men de er ikke viktige for ALLE brukerne. Vi prøver å begrense antall pakker som er i [extra], rett og slett fordi vi kanskje kommer til å ende opp med for mange pakker som ingen får tid til å vedlikeholde.
I [unstable] finner vi programvare vi gjerne vil ha i [extra], men som er for ustabilt for øyeblikket. Av og til støtter vi også programvare hentet gjennom versjon-kontroll systemer som SubVersion og CVS. I øyeblikket tror jeg du finner en svn-versjon av mplayer i [unstable].
[testing] er hvor vi tester alle pakkene våre før de blir lagt til i [core] eller [extra]. Vi krever at alle [core] pakker får litt tid i [testing], så vi kan være sikre på at det er helt stabilt før vi sender det videre til alle Arch brukerne. Når det gjelder pakker som skal til [extra] lar vi den som er ansvarlig selv bestemme om den først skal i [testing].
Og så har vi [community] som er vedlikeholdt av TUene og AUR-miljøet. Pakker som ender opp i [community] har vanligvis fått en del stemmer i AUR, eller er noe en TU liker og bruker.
Hvorfor ikke kombinere [extra] og [community]?
De er vedlikeholdt av to helt forskjellige grupper mennesker, og på forskjellige måter. Jeg har faktisk tenkt på dette, men med vår nåværende infrastruktur er det umulig. En kul ide ville vært å flytte pakkebrønnene over til et SVN-basert system, og brukt et AuthZ-basert sikkerhetssystem for å hindre TU-er å endre pakker som håndteres av kjerne-teamet og omvendt. F.eks. ville det ikke blitt populært om en TU hadde gjort endringer som hadde skapt problemer i apache-pakken.
Noen fremtidsplaner for å forbedre pacman?
Nå er ikke jeg sjefen for utviklingen av pacman lenger. Dan McGee er sjefen der nå, og han gjør en fantastisk jobb. Vi har også mange aktive utviklere som jobber med spennende ting, så det er vanskelig å si nøyaktig hvor pacman kommer til å være i tiden fremover. Men jeg regner med at det kommer til å bli mer kode-orientert enn noe annet. Det hadde vært flott å se et oversiktelig og intuativt grensesnitt til libalpm ("backenden" av pacman), slik at andre får en lettere jobb med å utvikle alternative brukersnitt. Akkurat nå er det ikke så enkelt som det burde være.