The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools, but are not part of the packaged software; they are, within the package, what is called its “meta-information” - information about other information.
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
The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc., in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:
<<: 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.
The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.
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 (f.eks. 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
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.32.1 present in Bullseye). 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 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
Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.
This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.
5.2.1.5. Erstatte filer: Replaces-feltet
The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.
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.
In addition to the
control file, the
control.tar.gz archive for each Debian package may contain a number of scripts, called by
dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails,
dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).
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 f.eks. 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.
During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 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 an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.
Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).
De nye pakkefiler er så pakket ut. Hvis en fil allerede finnes, blir den erstattet, men en sikkerhetskopi lages midlertidig.
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
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.
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.
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 calls the prerm script and passes the remove argument.
dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.
dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.
For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.
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.
The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.
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 f.eks. 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.
