Debian-pakken er ikke bare et arkiv med filene tiltenkt installasjon. Den er en del av en større helhet, og den beskriver forholdet til andre Debian-pakker (forutsetninger, avhengigheter, konflikter, forslag). Den inneholder også skript som gjør det mulig å kjøre kommandoer på ulike stadier i pakkens livsløp (installasjon, oppgraderinger, fjerning). Disse dataene brukes av pakkestyringsverktøyene, men er ikke en del av programvaren i pakken. I pakken er de det som kalles dens «metainformasjon» - informasjon om annen informasjon.
5.2.1. Bekrivelse; control-filen
Denne filen bruker en struktur som ligner på e-posthodefelter (som definert av
RFC 2822) og er fullt ut beskrevet i Debians retningslinjer og manualsidene
deb-control(5) og
deb822(5).
For eksempel, for apt, ser control-filen slik ut:
$ apt-cache show apt
Package: apt
Version: 2.2.4
Installed-Size: 4337
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Provides: apt-transport-https (= 2.2.4)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0
Recommends: ca-certificates
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base
Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10)
Description-en: commandline package manager
This package provides commandline tools for searching and
managing as well as querying information about packages
as a low-level access to all features of the libapt-pkg library.
.
These include:
* apt-get for retrieval of packages and information about them
from authenticated sources and for installation, upgrade and
removal of packages together with their dependencies
* apt-cache for querying available information about installed
as well as installable packages
* apt-cdrom to use removable media as a source for packages
* apt-config as an interface to the configuration settings
* apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, devel::lang:ruby, hardware::storage,
hardware::storage:cd, implemented-in::c++, implemented-in::perl,
implemented-in::ruby, interface::commandline, network::client,
protocol::ftp, protocol::http, protocol::ipv6, role::program,
scope::application, scope::utility, suite::debian, use::downloading,
use::organizing, use::playing, use::searching, works-with-format::html,
works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: required
Filename: pool/main/a/apt/apt_2.2.4_amd64.deb
Size: 1491328
MD5sum: 24d53e8dd75095640a167f40476c0442
SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d
La oss gå gjennom noen av filtene opplistet av forrige kommando mer nøye.
5.2.1.1. Avhengigheter: Depends-feltet
Avhengighetene er definert i Depends-feltet i pakkens topptekst. Dette er en liste over vilkår som må oppfylles for at pakken skal fungere korrekt. Denne informasjonen blir brukt av verktøy som apt for å installere de påkrevde biblioteker, verktøy, drivere, og så videre i riktige versjoner som tar hensyn til avhengighetene i den pakken som skal installeres. For hver avhengighet er det mulig å begrense omfanget av versjoner som oppfyller denne betingelsen. Med andre ord, er det mulig å uttrykke det faktum at vi trenger pakken libc6 i en versjon som er lik eller større enn «2.15» (skrevet “libc6 (>= 2.15)”). For versjonssammenligning er operatorene som følger:
<<: mindre enn;
<=: mindre enn eller lik;
=: er lik (merk at “2.6.1” er ikke lik “2.6.1-1”);
>=: større enn eller lik;
>>: større enn.
Komma brukes som skilletegn i listen med vilkår som må oppfylles. Komma tolkes som en logisk «og». I vilkårslisten tolkes vertikal strek («|») som logisk «eller» (det er en inkluderende «eller», ikke en eksklusiv «enten/eller»). «eller» har høyere prioritet enn «og» og kan det brukes så mange ganger som nødvendig. Dermed kan avhengigheten «(A eller B) og C» skrives som
A | B, C. Derimot må uttrykket «A or (B and C)» skrives som «(A or B) og (A or C)», ettersom
Depends-feltet ikke tolerere parenteser som forandrer prioritetsrekkefølgen mellom de logiske operatorene «eller» og «og». Dermed skal dette tilfelle skrives som
A | B, A | C.
Avhengighetssystemet er en god mekanisme for å sikre at et program fungerer, men det har en annen anvendelse med «metapakker». Dette er tomme pakker som kun beskriver avhengigheter. De muliggjør installasjon av en konsistent gruppe av programmer forhåndsvalgt av metapakkeutvikleren; slik at, apt install metapakke automatisk installerer alle disse programmene ved hjelp av metapakkens avhengigheter. gnome, kde-full og linux-image-amd64-pakkene er eksempler på metapakker.
5.2.1.2. Konflikter: Conflicts-feltet
Conflicts-feltet indikerer når en pakke ikke kan installeres samtidig med en annen. De vanligste årsakene er at begge pakkene inkluderer en fil med samme navn og sti, tilbyr den samme tjenesten fra samme TCP-port, eller ville hindret hverandres drift.
dpkg vil avslå å installere en pakke hvis det utløser en konflikt med en allerede installert pakke, bortsett fra hvis den nye pakken presiserer at den vil «erstatte» den installerte pakken, i så fall vil dpkg velge å erstatte den gamle pakken med den nye. apt følger alltid dine instruksjoner: Hvis du velger å installere en ny pakke, vil den automatisk tilby å avinstallere pakken som utgjør et problem.
5.2.1.3. Manglende samsvar: Breaks-feltet
Breaks-feltet har en effekt lik Conflicts-feltet, men med en spesiell mening. Det signaliserer at installasjonen av en pakke vil «ødelegge» for en annen pakke (eller bestemte versjoner av den). Generelt er manglende samsvar mellom to pakker forbigående, og Breaks-forholdet refererer spesifikt til de inkompatible versjonene.
dpkg vil avslå å installere en pakke som ødelegger for en allerede installert pakke, og apt vil forsøke å løse problemet ved å oppdaterte pakken som ville blitt ødelagt, til en nyere versjon (som forventes å være fikset, og således kompatibel igjen).
Denne typen situasjoner kan oppstå ved oppdateringer uten bakoverkompatibilitet: Det er tilfellet hvis den nye versjonen ikke lenger fungerer med en eldre versjon, og fører til en feil i et annet program uten å ta spesielle forholdsregler. Breaks-feltet hindrer brukeren å komme inn i disse problemene.
5.2.1.4. Tilbudte elementer: Provides-feltet
Dette feltet introduserer et interessant konsept for en «virtuell pakke». Det har mange oppgaver, men to er av særlig betydning. Den første rollen består i å bruke en virtuell pakke for å knytte en generisk tjeneste til den (pakken «tilbyr»-tjenesten). Den andre angir at en pakke fullstendig erstatter den andre, og at for dette formål kan den også tilfredsstille de avhengigheter som den andre ville tilfredsstille. Det er således mulig å opprette en erstatningspakke uten å måtte bruke samme pakkenavn .
5.2.1.4.1. Tilby en «Tjeneste»
La oss diskutere det første tilfellet i større detalj med et eksempel: Alle e-posttjenere, for eksempel postfix eller sendmail sies å «tilby» den virtuelle mail-transport-agent-pakken. Dermed behøer alle pakker som trenger denne tjenesten for å være funksjonelle (for eksempel en e-postlistebehandler, som smartlist, eller sympa) kun å oppgi i sine avhengigheter at det krever en mail-transport-agent i stedet for å angi en stor og ufullstendig liste over mulige løsninger (for eksempel postfix | sendmail | exim4 | …). Videre er det nytteløst å installere to e-posttjenere på samme maskin, noe som er grunnen til at begge disse pakkene viser en konflikt med den virtuelle pakken mail-transport-agent. En konflikt mellom en pakke og den selv ignoreres av systemet, men denne teknikken vil hindre installasjon av to e-posttjenere ved siden av hverandre.
5.2.1.4.2. Utbyttbarheten med en annen pakke
Provides-feltet er også interessant når innholdet av en pakke inngår i en større pakke. For eksempel, libdigest-md5-perl-Perl-modul var en valgfri modul i Perl 5.6, og er integrert som standard i Perl 5.8 (og senere versjoner som 5.31.1 som ligger i Bullseye). Som sådan har pakken perl siden versjon 5.8 annonsert Provides: libdigest-md5-perl slik at avhengighetene på denne pakken er imøtekommet dersom brukeren har Perl 5.8 (eller nyere). Selve libdigest-md5-perl-pakken har etter hvert blitt slettet, siden den ikke lenger har noe formål etter at gamle Perl-versjoner ble fjernet.
Denne funksjonen er svært nyttig, siden det aldri er mulig å forutse fremtidig utvikling , og det er nødvendig både å kunne gi foreldet programvare nye navn, og kunne utføre automatiske utskiftinger.
5.2.1.4.3. Tidligere begrensninger
Virtuelle pakker pleide å ha noen begrensninger, den mest betydningsfulle var mangelen på et versjonsnummer. For å gå tilbake til det forrige eksemplet, en avhengighet som Depends: libdigest-md5-perl (>= 1.6), ville, tross tilstedeværelsen av Perl 5.10, ville aldri ha blitt betraktet som tilfredsstilt av pakkesystemet — mens den i virkeligheten mest sannsynlig ble tilfredsstilt. Uvitende om dette, valgte pakkesystemet det minst risikable alternativet, ved å anta at versjonene ikke samsvarer.
Denne begrensningen er opphevet i dpkg 1.17.11, og er ikke lenger relevant. Pakker, som perl 5.32.1, kan tilordne en versjon til de virtuelle pakker pakkene tilbyr, med en avhengighet som Provides: libdigest-md5-perl (= 2.55.01), og dermed la andre pakke bruke versjonerte avhengigheter.
5.2.1.5. Erstatte filer: Replaces-feltet
Replaces-feltet indikerer at pakken inneholder filer som også er tilstede i en annen pakke, men at pakken har lov til å erstatte dem. Uten at dette spesifiseres, klarer ikke dpkg å installere pakken, og sier at den ikke kan overskrive filene i en annen pakke (teknisk er det mulig å tvinge den til å gjøre det med --force-overwrite-valget, men dette regnes ikke som en standard operasjon). Dette gjør det mulig å identifisere potensielle problemer, og krever at vedlikeholderen ser på saken før vedkommende velger å legge inn et slikt felt.
Bruken av dette felt er berettiget når pakkenavn endres, eller når en pakke er inkludert i en annen. Dette skjer også når vedlikeholderen bestemmer seg for å distribuere filer ulikt mellom forskjellige binære pakker produsert fra samme kildepakke, det vil si når en erstattet fil ikke lenger tilhører den gamle pakken, men bare til den nye.
Hvis alle filene i en installert pakke er blitt erstattet, så vurderes det å fjerne pakken. Sist, men ikke minst, så oppmundrer dette feltet også dpkg til å fjerne den erstattede pakken der det er en konflikt.
I tillegg til filen
control så kan
control.tar.gz-arkivet i hver Debian-pakke inneholde et antall skript, som kjøres av
dpkg på ulike stadier under håndteringen av en pakke. Debian-retningslinjene beskriver de mulige tilfellene i detalj, og spesifiserer skriptene som kjøres, og argumentene de mottar. Disse sekvensene kan være kompliserte, på grunn av at dersom et av skriptene svikter så vil
dpkg prøve å gå tilbake til en tilfredsstillende tilstand ved å avbryte installasjonen eller fjerningen som pågår (i den grad det er mulig).
Generelt er preinst-skriptet utført før installasjonen av pakken, mens postinst følger etter dette. På samme måte er prerm aktivert før en pakke fjernes og postrm etterpå. Oppdatering av en pakke tilsvarer å fjerne den tidligere versjonen og installasjon av den nye. Det er ikke mulig å beskrive i detalj alle mulige scenarier her, men vi vil diskutere de to vanligste: En installasjon/oppdatering, og en fjerning.
5.2.2.1. Installasjon og oppgradering
I løpet av innledende installasjon og for hver oppgradering av en pakke, kaller dpkg de såkalte vedlikeholderskriptene, som for eksempel prerm eller preinst-skriptene. Disse kan utføre ytterligere handlinger i forskjellige stadier av en pakkes livssyklus. Skriptnavn som innledes med «new-» er skript fra den nye versjonen av en pakke som blir installert eller det blir oppgradert til. Skriptnavn innledet av «old-» er skript fra den gamle versjonen av pakken det blir oppgradert fra.
Hver bruk av dpkg sender gitte argumenter til hvert skript, som for eksempel upgrade new-version. Påkalt skript kan deretter enten håndtere argumentene og utføre en gitt handling, eller ignorere argumentene og svare med en 0-avslutningskode hvis ingenting må gjøres i respektivt steg. I praksis er det mange pakker som ikke må utføre handlinger i hvert steg av livssyklusen. Derav vil et typisk oppsettsskript prøve å finne et gitt argument og ignorere alle andre, noe som betyr at det igjen avslutter med 0.
Dette skjer i løpet av en installasjon (eller en oppgradering). old-version, new-version og last-version-configured-argumentene er plassholdere for de faktiske (gamle og nye) versjonsnumrene for pakken:
For en oppdatering så kjører dpkg skriptet old-prerm og sender inn upgrade ny-versjon som argument.
Fremdeles for en oppdatering, dpkg utfører så new-preinst-skruptet med argumentene upgrade gammel versjon. Som en innledende installasjon igangsetter det new-preinst-skriptet og sender install som argument. Den kan legge til den gamle versjonen i den siste parameteren, hvis pakken allerede er installert og deretter fjernet (men ikke rensket vekk, og dermed forblir oppsettsfilene bevart).
De nye pakkefiler er så pakket ut. Hvis en fil allerede finnes, blir den erstattet, men en sikkerhetskopi lages midlertidig.
For en oppdatering så kjører dpkg skriptet old-postrm med upgrade ny-versjon som argument.
dpkg oppdaterer alle interne data (filliste, oppsettsskript, og så videre) og fjerner sikkerhetskopier av de erstattede filene. Det er det ingen vei tilbake: dpkg har ikke lenger tilgang til alle de elementer som er nødvendige for å gå tilbake til slik det var før.
Til slutt setter dpkg opp pakken ved å utføre skriptet new-postinst med argumentene configure siste-oppsatte-versjon.
5.2.2.2. Fjerning av pakke
Stegene for å fjerne en pakke tilsvarer dem for installasjonsstegene. Hovedforskjellen er at fjerningsskriptene for pakken påkalles:
dpkg kaller skriptet prerm og sender inn argumentet remove.
dpkg fjerner alle filer i pakken, med unntak av oppsettsfiler og vedlikeholderskript.
dpkg utfører skriptet postrm og sender inn argumentet remove. Etterpå blir alle oppsettsskriptene, unntatt skriptet postrm, fjernet. Prosessen stopper her med mindre brukeren har brukt «purge»-tilvalget.
For å renske vekk pakken (kommandoen utført med dpkg --purge eller dpkg -P), så slettes også oppsettsfilene, i tillegg til et bestemt antall kopier (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) og midlertidige filer; deretter utfører dpkg skriptet postrm med purge.
De fire skriptene detaljert ovenfor er supplert med et config skript, fra pakker som bruker debconf for å få informasjon fra brukeren inn i oppsettet. Under installasjonen definerer dette skriptet i detalj de spørsmålene som stilles fra debconf. Svarene registreres i debconf-databasen for fremtidig bruk. Skriptet er generelt utført av apt før pakkene installeres én etter én, for å samle alle spørsmålene og stille dem til brukeren når prosessen begynner. Før- og etter-installasjonsskripter kan deretter bruke denne informasjonen til å operere i tråd med brukerens ønsker.
5.2.3. Sjekksummer, Liste med oppsettfiler, med mere.
I tillegg til vedlikeholderskript og kontrolldata som allerede er nevnte i de forrige delene, kan control.tar.gz-arkivet av en Debian-pakke inneholde andre interessante filer.
Den første,
md5sums, inneholder MD5-sjekksummer for alle pakkens filer. Dens største fordel er at den gjør det mulig for
dpkg --verify (som vi vil se nærmere på i
Seksjon 14.3.4.1, «Gjennomgå pakker med dpkg --verify») og
debsums (fra pakken med samme navn; se
Seksjon 14.3.4.2, «Kontroll av pakker: debsums og dens begrensninger») å sjekke om disse filene har blitt endret etter installasjonen. Legg merke til at når denne filen ikke eksisterer (som kan være tilfelle for noen eldre pakker) vil
dpkg generere den dynamisk ved installasjonstidspunktet (og lagre den i databasen til dpkg akkurat som andre kontrollfiler).
Filen conffiles viser pakkefiler som må håndteres som oppsettsfiler (se også deb-conffiles(5)). Oppsettsfiler kan endres av administratoren, og dpkg vil prøve å bevare disse endringene under en pakkeoppdatering.
I praksis oppfører dpkg seg i denne situasjonen seg så intelligent som mulig: Hvis ikke den standard oppsettsfilen har endret seg mellom de to versjonene, gjør den ingenting. Derimot, hvis filen er endret, vil dpkg prøve å oppdatere den. To tilfeller er mulig; enten at administrator ikke har rørt oppsettsfilen, og i så fall installerer dpkg automatisk den nye versjonen, eller så er filen endret. I så tilfelle spør dpkg administratoren om hvilken versjon de ønsker å bruke (den gamle med modifikasjoner, eller den nye som følger med pakken). For å bistå i denne beslutningen tilbyr dpkg å vise en «diff» som viser forskjellen mellom de to versjonene. Hvis brukeren velger å beholde den gamle versjonen, vil den nye lagres på samme sted i en fil med .dpkg-dist-ending. Hvis brukeren velger den nye versjonen, blir den gamle beholdt i en fil med .dpkg-old-endingen. En annen tilgjengelig handling er å straks avbryte dpkg for å redigere filen og forsøke å sette inn igjen de relevante endringene (tidligere identifisert med diff).
Kontrollarkivet inneholder ofte også andre filer, som triggers, shlibs, eller symbols. Disse er godt beskrevet i deb-triggers(5), deb-shlibs(5), og deb-symbols(5).
Utløsere ble introdusert for å redusere mengden dupliserte begivenheter i løpet av pakkeinstallasjoner, som for eksempel filregistreringer, eller katalog/database-oppdateringsgjøremål. Pakker kan definere egne eller aktivere definerte utløsere. Mer fullstendig dokumentasjon er å finne i
/usr/share/doc/dpkg/triggers.txt.gz.
shlibs-er et eldre og enklere alternativ til symbols-systemet for deklarering av avhengigheter for delte bibliotek. Det definerer pakkenavnet og versjonen man finner en spesifikk SONAME-versjon eller delt bibliotek i. Det nyere symbols-systemet tillater definering av avhengigheten ved å istedenfor spore symbolene, og når de har blitt introdusert eller endret i biblioteket.
