Debian-pakken er ikke bare et arkiv med filene beregnet for installasjon. Det er en del av en større helhet, og den beskriver forholdet til andre Debian-pakker (avhengigheter, konflikter, forslag). Den gir også skript som muliggjør kjøring av kommandoer på forskjellige stadier i pakkens livssyklus (installasjon, fjerning, oppgraderinger). Disse dataene brukes av pakkens styringsverktøy, men er ikke en del av pakkens programvare; I pakken er de det som kalles dens «meta-informasjon» (informasjon om annen informasjon).
5.2.1. Bekrivelse; kontroll-filen
Denne filen bruker en struktur tilsvarende e-postoverskrifter (som definert av RFC 2822). For eksempel, for apt, ser kontroll-filen ut som den følgende:
$ apt-cache show apt
Package: apt
Version: 1.4.8
Installed-Size: 3539
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: apt-utils (<< 1.3~exp2~)
Depends: adduser, gpgv | gpgv2 | gpgv1, debian-archive-keyring, init-system-helpers (>= 1.18~), libapt-pkg5.0 (>= 1.3~rc2), libc6 (>= 2.15), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2)
Recommends: gnupg | gnupg2 | gnupg1
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), powermgmt-base, python-apt
Breaks: apt-utils (<< 1.3~exp2~)
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, sound::player, suite::debian,
use::downloading, use::organizing, use::searching, works-with::audio,
works-with::software:package, works-with::text
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_1.4.8_amd64.deb
Size: 1231676
MD5sum: 4963240f23156b2dda3affc9c0d416a3
SHA256: bc319a3abaf98d76e7e13ac97ab0ee7c238a48e2d4ab85524be8b10cfd23d50d
5.2.1.1. Avhengigheter: Avhengig-feltet
Avhengighetene er definert i Avhenger-feltet i pakkens topptekst. Dette er en liste over vilkår som må oppfylles for at pakken skal fungere riktig. Denne informasjonen blir brukt av verktøy som apt for å installere de forutsatte biblioteker i riktige versjoner som tar hensyn til de 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 operatørene 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.
In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written
A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the
Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written
A | B, A | C.
Avhengighetssystemet er en god mekanisme for å sikre driften av et program, men det har en annen anvendelse med «Meta-pakker». Dette er tomme pakker som kun beskriver avhengigheter. De muliggjør installasjon av en konsistent gruppe av programmer forhåndsvalgt av Meta-pakkeutvikleren; slik at, apt install meta-pakke vil automatisk installere alle disse programmene ved hjelp av Meta-pakkens avhengigheter. gnome, kde-full og linux-image-amd64-pakkene er eksempler på Meta-pakker.
5.2.1.2. Konflikter: Konflikter-feltet
Konflikt-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, gir den samme tjenesten fra samme TCP-port, eller ville hindre 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: Pauser-feltet
Pauser-feltet har en effekt lik Konflikter-feltet, men med en spesiell mening. Det signaliserer at installasjonen av en pakke vil «bryte» med en annen pakke (eller bestemte versjoner av den). Generelt er manglende samsvar mellom to pakker forbigående, og Pauser-forholdet refererer spesifikt til de inkompatible versjonene.
dpkg vil avslå å installere en pakke som bryter med en allerede installert pakke, og apt vil forsøke å løse problemet ved å oppdaterte pakken som ville blitt brutt, 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. Pauser-feltet hindrer brukeren å komme inn i disse problemene.
5.2.1.4. Leveranser: 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. Levere 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 å «levere» den virtuelle mail-transport-agent-pakken. Derfor, alle pakker som trenger denne tjenesten for å være funksjonelle (f.eks en postliste manager, som for eksempel smartlist, eller sympa) oppgir bare i sine avhengigheter at det krever en mail-transport-agent i stedet for å angi en stor, men fremdeles ufullstendig liste over mulige løsninger (f.eks postfix | sendmail | exim4 | …). Videre er det nytteløst å installere to 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 posttjenere ved siden av hverandre.
5.2.1.4.2. Utbyttbarheten med en annen pakke
The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.24 present in Stretch). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.
Denne funksjonen er svært nyttig, siden det aldri er mulig å forutse tilfeldigheter i utviklingsarbeid, 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 Avhengig: libdigest-md5-perl (>= 1.6), ville, tross tilstedeværelsen av Perl 5.10, aldri bli betraktet som tilfredsstilt av pakkesystemet - mens den i virkeligheten mest sannsynlig er tilfredsstilt. Uvitende om dette, valgte pakkesystemet det minst risikable alternativet, ved å anta at versjonene ikke samsvarer.
This limitation has been lifted in dpkg 1.17.11, and is no longer relevant in Stretch. Packages can assign a version to the virtual packages they provide with a dependency such as Provides: libdigest-md5-perl (= 1.8).
5.2.1.5. Erstatte filer: Erstatte felt
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, feiler dpkg 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: 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, er pakken klar til å bli fjernet. Endelig, dette feltet oppmuntrer også dpkg til å fjerne den erstattede pakken der det er en konflikt.
I tillegg til kontroll-filen, kan control.tar.gz-katalogen for hver Debian-pakke inneholde et antall skripter, hentet av dpkg på ulike stadier i behandlingen av en pakke. Debian Policy beskriver de mulige tilfellene i detalj, og spesifiserer de skript det bes om, og de argumentene de mottar. Disse sekvensene kan være kompliserte, fordi dersom et av skriptene svikter, vil dpkg prøve å gå tilbake til en tilfredsstillende tilstand ved å avslutte installasjonen, eller fjerne dem underveis (i den grad det er mulig).
Generelt er preinst-skriptet utført før installasjonen av pakken, mens postinst følger etter. 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
Her er hva som skjer under en installasjon (eller en oppdatering):
For en oppdatering, kjører dpkg varianten old-prerm upgrade new-version.
Fremdeles for en oppdatering, dpkg utfører så ny-preinst upgrade gammel-versjon. Som en første installasjon igangsetter den ny-preinst install. Den kan legge til den gamle versjonen i den siste parameteren, hvis pakken allerede er installert og deretter fjernet (men ikke renset vekk, oppsettsfilene er bevart).
De nye pakkefiler er så pakket ut. Hvis en fil allerede finnes, blir den erstattet, men en sikkerhetskopi lages midlertidig.
For en oppdatering, utfører dpkg old-postrm upgrade new-version.
dpkg oppdaterer alle interne data (filliste, oppsettsskript, etc.) 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 ny-postinst configure siste-oppsatte-versjon.
5.2.2.2. Fjerning av pakke
Her er det som skjer når en pakke fjernes:
dpkg kaller prerm remove.
dpkg fjerner alle filer i pakken, med unntak av oppsettsfiler og oppsettsskript.
dpkg executes postrm remove. Alle oppsettsskriptene, unntatt postrm, er fjernet. Hvis brukeren ikke har brukt «purge»-tilvalget, stopper prosessen her.
For en fullstendig fjerning av pakken (kommandoen gitt med dpkg --purge eller dpkg -P), er oppsettsfilene også slettet, så vel som et bestemt antall kopier (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) og midlertidige filer; dpkg så utfører postrm purge.
De fire skriptene detaljert ovenfor er supplert med et config skript, fra pakker som bruker debconf for å få brukerinformasjon til oppsett. Under installasjonen definerer dette skriptet i detalj de spørsmålene som stilles fra debconf. Svarene registreres i debconf-databasen for fremtidig henvisning. Skriptet er generelt utført av apt før pakkene installeres én etter én, for å gruppere 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 etter brukerens ønsker.
5.2.3. Checksums, Liste med konfiguasjonsfiler
I tillegg til vedlikeholderens skript og styringsdata som allerede er nevnt i forrige avsnitt,
control.tar.gz-katalogen, kan Debian-pakken inneholde andre interessante filer. Den første,
md5sums, inneholder MD5 checksums (kontrollsummer) for alle pakkens filer. Dens største fordel er at den tillater
dpkg --verify (som vi vil se nærmere på i
Seksjon 14.3.3.1, «Gjennomgå pakker med dpkg --verify») for å sjekke om disse filene har blitt endret etter installasjonen. Legg merke til at når denne filen ikke eksisterer, vil
dpkg generere den dynamisk ved installasjonstidspunktet (og lagre den i dpkgs database akkurat som andre kontrollfiler).
conffiles lister pakkefiler som må behandles som oppsettsfiler. Oppsettsfiler kan endres av administrator, og dpkg vil forsøke å ta vare på disse forandringene under pakkeoppdateringen.
I praksis, i denne situasjonen, oppfører dpkg seg så intelligent som mulig: Hvis ikke den standard oppsettsfilen har endret seg mellom de to versjonene, gjør det ingenting. Hvis, derimot, filen er endret, vil den prøve å oppdatere denne filen. To tilfeller er mulig; enten at administrator ikke har rørt denne oppsettsfilen, og i så fall installerer dpkg automatisk den nye versjonen, eller, filen er 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).
