0 - en to nb-NO translation catalogue (254 entries)

en: Binary package
nb-NO: Binærpakke

en: Source package
nb-NO: Kildepakke

en: package
nb-NO: pakke

en: dependencies
nb-NO: avhengigheter

en: conflict
nb-NO: konflikt

en: Packaging System: Tools and Fundamental Principles
nb-NO: Pakkesystem: Verktøy og grunnleggende prinsipper

en: As a Debian system administrator, you will routinely handle <filename>.deb</filename> packages, since they contain consistent functional units (applications, documentation, etc.), whose installation and maintenance they facilitate. It is therefore a good idea to know what they are and how to use them.
nb-NO: Som Debian-systemadministrator vil du rutinemessig håndtere <filename>.deb</filename>-pakker, siden de inneholder konsistente funksjonelle enheter (programmer, dokumentasjon, etc.), som gjør installasjon og vedlikehold mulig. Det er derfor en god idé å vite hva de er, og hvordan du bruker dem.

en: This chapter describes the structure and contents of “binary” and “source” packages. The former are files directly usable by <command>dpkg</command>, while the latter contain the source code, as well as instructions for building binary packages.
nb-NO: Dette kapitlet beskriver strukturen og innholdet av «binær»- og «kilde»-pakker. Førstnevnte er filer, som kan brukes direkte av <command>dpkg</command>, mens sistnevnte inneholder kildekoden, så vel som instruksjoner for bygging av binære pakker.

en: Structure of a Binary Package
nb-NO: Binærpakkestruktur

en: <primary>package</primary><secondary>binary package</secondary><seealso><filename>.deb</filename></seealso>
nb-NO: <primary>pakke</primary><secondary>binærpakke</secondary><seealso><filename>.deb</filename></seealso>

en: The Debian package format is designed so that its content may be extracted on any Unix system that has the classic commands <command>ar</command>, <command>tar</command>, and <command>xz</command> or sometimes <command>gzip</command> or <command>bzip2</command>. This seemingly trivial property is important for portability and disaster recovery.
nb-NO: Pakkeformatet til Debian er utformet slik at innholdet kan pakkes ut i et Unix-system som har de klassiske kommandoene <command>ar</command>, <command>tar</command>, og <command>xz</command> eller noen ganger <command>gzip</command> eller <command>bzip2</command>. Denne tilsynelatende trivielle egenskapen er viktig for å virke på mange plattformer og for gjenoppretting etter alvorlige uhell.

en: Imagine, for example, that you mistakenly deleted the <command>dpkg</command> program, and that you could thus no longer install Debian packages. <command>dpkg</command> being a Debian package itself, it would seem your system would be done for... Fortunately, you know the format of a package and can therefore <ulink url="https://www.debian.org/distrib/packages#search_packages">download</ulink> the <filename>.deb</filename> file of the <emphasis role="pkg">dpkg</emphasis> package and install it manually (see sidebar <xref linkend="sidebar.dpkg-apt-ar" />). If by some misfortune one or more of the programs <command>ar</command>, <command>tar</command> or <command>gzip</command>/<command>xz</command>/<command>bzip2</command> have disappeared, you will only need to copy the missing program from another system (since each of these operates in a completely autonomous manner, without dependencies, a simple copy will suffice). If your system suffered some even more outrageous fortune, and even these don't work (maybe the deepest system libraries are missing?), you should try the static version of <command>busybox</command> (provided in the <emphasis role="pkg">busybox-static</emphasis> package), which is even more self-contained, and provides subcommands such as <command>busybox ar</command>, <command>busybox tar</command> and <command>busybox xz</command>.
nb-NO: Forestill deg, for eksempel, at du ved en feil har slettet <command>dpkg</command>-programmet, og at du ikke lenger kan installere Debian-pakker. Ettersom selve <command>dpkg</command> er en Debian-pakke virker det hele håpløst ... Heldigvis vet du formatet for pakker, og kan derfor <ulink url="https://www.debian.org/distrib/packages#search_packages">laste ned</ulink> <filename>.deb</filename>-filen tilhørende <emphasis role="pkg">dpkg</emphasis>-pakken, og installere den manuelt (sjekk sidefeltet <xref linkend="sidebar.dpkg-apt-ar" />). Hvis, ved et uhell, en eller flere av programmene <command>ar</command>, <command>tar</command> eller <command>gzip</command>/<command>xz</command>/<command>bzip2</command> har forsvunnet, trenger du bare å en kopi av det manglende programmet fra et annet system (siden hver av disse opererer helt selvstendig, uten avhengigheter). Hvis systemet kneler enda mer, slik at selv disse ikke fungerer (kanskje de mest grunnleggende systembibliotekene mangler?), kan du prøve den statiske versjonen av <command>busybox</command> (fremskaffet fra <emphasis role="pkg">busybox-static</emphasis>-pakken), som er enda mer selvstendig, og gir delkommandoer som <command>busybox ar</command>, <command>busybox tar</command> og <command>busybox xz</command>.

en: <emphasis>In case of a misfortune you better also have a backup of your system (see <xref linkend="sect.backup" />).</emphasis>
nb-NO: <emphasis> I tilfelle uhell bør du helst ha sikret deg en sikkerhetskopi av systemet (se <xref linkend="sect.backup" />). </emphasis>

en: <emphasis>TOOLS</emphasis> <command>dpkg</command>, <command>APT</command> and <command>ar</command>
nb-NO: <emphasis>VERKTØY</emphasis> <command>dpkg</command>, <command>APT</command>, og <command>ar</command>

en: <primary>APT</primary><secondary><command>apt</command>, command</secondary><see><command>apt</command></see>
nb-NO: <primary>APT</primary><secondary><command>apt</command>, kommando</secondary><see><command>apt</command></see>

en: <command>dpkg</command> is the program that handles <filename>.deb</filename> files (binary packages), notably extracting, analyzing, and unpacking them.
nb-NO: <command>dpkg</command> er programmet som håndterer <filename>.deb</filename>-filer (binærpakker), og spesifikt pakker ut, analyserer og åpner dem.

en: <acronym>APT</acronym> (the abbreviation of "Advanced Packaging Tool") is a group of programs that allows the execution of higher-level modifications to the system: installing or removing a package (while keeping dependencies satisfied), updating and upgrading the system, listing the available packages, etc.
nb-NO: <acronym>APT</acronym> (forkortelsen for "Advanced Packaging Tool") er en gruppe programmer som tillater å utføre høyere-nivå endringer i systemet, som installasjon eller fjerning av en pakker (mens det holder kontroll på avhengighetene), oppdatering og oppgradering av systemet, opplisting av tilgjengelige pakker, etc.

en: As for the <command>ar</command> program, provided by the <emphasis role="pkg">binutils</emphasis> package, it allows handling files of the same name:
nb-NO: <command>ar</command>-programmet som tilbys av <emphasis role="pkg">binutils</emphasis>-pakken tilbyr håndtering av filer med samme navn:

en: <primary>decompressing, binary package</primary>
nb-NO: <primary>dekomprimering, binærpakke</primary>

en: <primary>uncompressing, binary package</primary>
nb-NO: <primary>pakke ut, binærpakke</primary>

en: <primary>unpacking</primary><secondary>binary package</secondary>
nb-NO: <primary>utpakking</primary><secondary>binærpakke</secondary>

en: <command>ar t <replaceable>archive</replaceable></command> displays the list of files contained in such an archive,
nb-NO: <command>ar t <replaceable>arkiv</replaceable></command> viser listen over filene som er å finne i et slikt arkiv,

en: <command>ar x <replaceable>archive</replaceable></command> extracts the files from the archive into the current working directory,
nb-NO: <command>ar x <replaceable>arkiv</replaceable></command> pakker ut filene fra arkivet til nåværende arbeidsmappe,

en: <command>ar d <replaceable>archive</replaceable> <replaceable>file</replaceable></command> deletes a file from the archive, etc.
nb-NO: <command>ar d <replaceable>arkiv</replaceable> <replaceable>fil</replaceable></command> sletter en fil fra arkivet, osv.

en: Its man page <citerefentry><refentrytitle>ar</refentrytitle><manvolnum>1</manvolnum></citerefentry> documents all its other features. <command>ar</command> is a very rudimentary tool that a Unix administrator would only use on rare occasions, but admins routinely use <command>tar</command>, a more evolved archive and file management program. This is why it is easy to restore <command>dpkg</command> in the event of an erroneous deletion. You would only have to download the Debian package and extract the content from the <filename>data.tar.xz</filename> archive in the system's root (<filename>/</filename>):
nb-NO: Manualsiden <citerefentry><refentrytitle>ar</refentrytitle><manvolnum>1</manvolnum></citerefentry> dokumenter alle andre egenskaper. <command>ar</command> er et svært rudimentært verktøy som en Unix administrator bare sjelden vil bruke, mens en admin regelmessig bruker <command>tar</command>, et mer avansert arkiv og filhåndteringsprogram. Dette er grunnen til at det er så enkelt å gjenopprette <command>dpkg</command> hvis den blir slettet ved en feil. Du trenger bare å laste ned Debian-pakken, og pakke ut innholdet fra <filename>data.tar.gxz</filename>-arkivet i rotsystemet. (<filename>/</filename>):

en: <emphasis>BACK TO BASICS</emphasis> Man page notation
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Manualsideformatet

en: It can be confusing for beginners to find references to “<citerefentry><refentrytitle>ar</refentrytitle><manvolnum>1</manvolnum></citerefentry>” in the literature. This is generally a convenient means of referring to the man page entitled <literal>ar</literal> in section 1.
nb-NO: Det kan være forvirrende for nybegynnere å finne referanser til “<citerefentry><refentrytitle>ar</refentrytitle><manvolnum>1</manvolnum></citerefentry>” i litteraturen. Det er generelt en beleilig måte å vise til en man-side med tittelen <literal>ar</literal> i seksjon 1.

en: Sometimes this notation is also used to remove ambiguities, for example to distinguish between the <command>printf</command> command that can also be indicated by <citerefentry><refentrytitle>printf</refentrytitle><manvolnum>1</manvolnum></citerefentry> and the <function>printf</function> function in the C programming language, which can also be referred to as <citerefentry><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
nb-NO: Noen ganger er denne merknaden også benyttet til å fjerne uklarheter, for eksempel å skille mellom <command>printf</command>-kommandoen, som også kan indikeres av <citerefentry><refentrytitle>printf</refentrytitle><manvolnum>1</manvolnum></citerefentry> og <function>printf</function>-funksjonen i programspråket C, som også kan bli vist til som <citerefentry><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>.

en: <xref linkend="solving-problems" /> discusses manual pages in further detail (see <xref linkend="sect.manual-pages" />).
nb-NO: Manualsider drøftes i <xref linkend="solving-problems" /> i større detalj (se <xref linkend="sect.manual-pages" />).

en: Have a look at the content of a <filename>.deb</filename> file:
nb-NO: Ta en titt på innholdet i en <filename>.deb</filename>-fil:

en: As you can see, the <command>ar</command> archive of a Debian package is comprised of three files:
nb-NO: Som du kan se, inneholder <command>ar</command>-arkivet i en Debian-pakke tre filer:

en: This is a text file which simply indicates the version of the <filename>.deb</filename> file package format version. In Debian <emphasis role="distribution">Bullseye</emphasis> it is still version 2.0.
nb-NO: Dette er en tekstfil som ganske enkelt indikerer versjonen til filformatet til <filename>.deb</filename>-filpakken. I Debian <emphasis role="distribution">Bullseye</emphasis> er den fremdeles versjon 2.0.

en: This archive file contains all of the available meta-information, like the name and version of the package as well as some scripts to run before, during or after (un-)installation of it. Some of the meta-information allows package management tools to determine if it is possible to install or uninstall it, for example according to the list of packages already on the machine, and if files shipped have been modified locally.
nb-NO: Denne arkivfilen inneholder all tilgjengelig metainformasjon, for eksempel pakkens navn og versjon, samt noen skript som skal kjøres før, under eller etter (av-)installasjon av den. Noe av metainformasjonen gjør det mulig for pakkeadministrasjonsverktøyet å avgjøre om det er mulig å installere eller avinstallere den, for eksempel vurdert opp mot listen over pakker som allerede er på maskinen, og om utsendte filer er endret lokalt.

en: This archive contains all of the files to be extracted from the package; this is where the executable files, libraries, documentation, etc., are all stored. Packages may use different compression formats, in which case the file will be named differently for <command>xz</command>, <command>bzip2</command> or <command>gzip</command>.
nb-NO: Dette arkivet inneholder alle filene som skal pakkes ut fra pakken; Det er her de kjørbare filene, bibliotekene, dokumentasjonen og så videre, er lagret. Pakker kan bruke forskjellige sammenpakkingsformater, i sådant fall vil filen navngis annerledes for <command>xz</command>, <command>bzip2</command> eller <command>gzip</command>.

en: Package Meta-Information
nb-NO: Pakke-metainformasjon

en: <primary>package meta-information</primary><seealso>meta-information</seealso>
nb-NO: <primary>pakke-metainformasjon</primary><seealso>metainformasjon</seealso>

en: <primary>package</primary><secondary>meta-information</secondary>
nb-NO: <primary>pakke</primary><secondary>metainformasjon</secondary>

en: <primary>package</primary><secondary>maintainer scripts</secondary>
nb-NO: <primary>pakke</primary><secondary>vedlikeholder-skript</secondary>

en: <primary>package</primary><secondary>checksums</secondary>
nb-NO: <primary>pakke</primary><secondary>sjekksummer</secondary>

en: Description: the <filename>control</filename> File
nb-NO: Bekrivelse; <filename>control</filename>-filen

en: <primary>package meta-information</primary>
nb-NO: <primary>pakke-metainformasjon</primary>

en: <primary>package</primary><secondary><filename>control</filename></secondary>
nb-NO: <primary>pakke</primary><secondary><filename>control</filename></secondary>

en: <primary><filename>control</filename></primary><seealso>package meta-information</seealso>
nb-NO: <primary><filename>control</filename></primary><seealso>pakkemetainformasjon</seealso>

en: This file uses a structure similar to email headers (as defined by <link linkend="sidebar.rfc">RFC 2822</link>) and is fully described in the Debian Policy and the manual pages <citerefentry><refentrytitle>deb-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> and <citerefentry><refentrytitle>deb822</refentrytitle><manvolnum>5</manvolnum></citerefentry>. <ulink type="block" url="https://www.debian.org/doc/debian-policy/ch-controlfields.html" />
nb-NO: Denne filen bruker en struktur som ligner på e-posthodefelter (som definert av <link linkend="sidebar.rfc">RFC 2822</link>) og er fullt ut beskrevet i Debians retningslinjer og manualsidene <citerefentry><refentrytitle>deb-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> og <citerefentry><refentrytitle>deb822</refentrytitle><manvolnum>5</manvolnum></citerefentry>. <ulink type="block" url="https://www.debian.org/doc/debian-policy/ch-controlfields.html" />

en: For example, for <emphasis role="pkg">apt</emphasis>, the <filename>control</filename> file looks like the following:
nb-NO: For eksempel, for <emphasis role="pkg">apt</emphasis>, ser <filename>control</filename>-filen slik ut:

en: Let us have a closer look at the purpose of some of the fields listed by the previous command.
nb-NO: La oss gå gjennom noen av filtene opplistet av forrige kommando mer nøye.

en: <emphasis>BACK TO BASICS</emphasis> RFC — Internet standards
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> RFC — Internett-standarder

en: <acronym>RFC</acronym> is the abbreviation of “Request For Comments”. An RFC is generally a technical document that describes what will become an Internet standard. Before becoming standardized and frozen, these standards are submitted for public review (hence their name). The <acronym>IETF</acronym> (Internet Engineering Task Force) decides on the evolution of the status of these documents (proposed standard, draft standard, or standard).
nb-NO: <acronym>RFC</acronym> er en forkortelse for «Request For Comments» (~ Forespørsel om kommentarer.) En RFC er generelt sett et teknisk dokument som beskriver det som skal bli en Internett-standard. Før de blir standardisert og fryst, sendes disse standardene inn til offentlig gjennomsyn (derav navnet). <acronym>IETF</acronym> (Internet Engineering Task Force) avgjør hvordan statusen til disse dokumentene utvikler seg (foreslått standard, utkast til standard, eller standard).

en: RFC 2026 defines the process for standardization of Internet protocols. <ulink type="block" url="http://www.faqs.org/rfcs/rfc2026.html" />
nb-NO: RFC 2026 definerer prosessen for standardisering av Internett-protokoller. <ulink type="block" url="http://www.faqs.org/rfcs/rfc2026.html" />

en: Dependencies: the <literal>Depends</literal> Field
nb-NO: Avhengigheter: <literal>Depends</literal>-feltet

en: <primary>dependency</primary>
nb-NO: <primary>avhengighet</primary>

en: <primary>package</primary><secondary>dependency</secondary>
nb-NO: <primary>pakke</primary><secondary>avhengighet</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Depends</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Depends</literal>, hodefelt</secondary>

en: <command>&lt;&lt;</command>: less than;
nb-NO: <command>&lt;&lt;</command>: mindre enn;

en: <command>&lt;=</command>: less than or equal to;
nb-NO: <command>&lt;=</command>: mindre enn eller lik;

en: <command>=</command>: equal to (note that “<literal>2.6.1</literal>” is not equal to “<literal>2.6.1-1</literal>”);
nb-NO: <command>=</command>: er lik (merk at “<literal>2.6.1</literal>” er ikke lik “<literal>2.6.1-1</literal>”);

en: <command>&gt;=</command>: greater than or equal to;
nb-NO: <command>&gt;=</command>: større enn eller lik;

en: <command>&gt;&gt;</command>: greater than.
nb-NO: <command>&gt;&gt;</command>: større enn.

en: <primary>meta-package</primary>
nb-NO: <primary>meta-pakke</primary>

en: <emphasis>DEBIAN POLICY</emphasis> <literal>Recommends</literal>, <literal>Suggests</literal>, and <literal>Enhances</literal> fields
nb-NO: <emphasis>DEBIAN-RETNINGSLINJER</emphasis> Feltene <literal>Recommends</literal>, <literal>Suggests</literal>, og <literal>Enhances</literal>

en: <primary>package</primary><secondary>recommendations</secondary>
nb-NO: <primary>pakke</primary><secondary>anbefalinger</secondary>

en: <primary>package</primary><secondary>suggestions</secondary>
nb-NO: <primary>pakke</primary><secondary>forslag</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Recommends</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Recommends</literal>, hodefelt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Suggests</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Suggests</literal>, hodefelt</secondary>

en: The <literal>Recommends</literal> and <literal>Suggests</literal> fields describe dependencies that are not compulsory. The “recommended” dependencies, the most important, considerably improve the functionality offered by the package but are not indispensable to its operation. The “suggested” dependencies, of secondary importance, indicate that certain packages may complement and increase their respective utility, but it is perfectly reasonable to install one without the others.
nb-NO: Feltene <literal>Recommends</literal> og <literal>Suggests</literal> beskriver ikke-påkrevde avhengigheter. De «anbefalte» avhengigheter, de viktigste, forbedrer vesentlig funksjonaliteten som tilbys av pakken, men er ikke uunnværlig for driften av dem. De «foreslåtte» avhengighetene, som er av underordnet betydning, indikerer at enkelte pakker kan utfylle og øke sin respektive nytteverdi, men det er helt fornuftig å installere en av dem uten de andre.

en: <primary>package</primary><secondary>enhancements</secondary>
nb-NO: <primary>pakke</primary><secondary>forbedringer</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Enhances</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Enhances</literal>, hodefelt</secondary>

en: The <literal>Enhances</literal> field also describes a suggestion, but in a different context. It is indeed located in the suggested package, and not in the package that benefits from the suggestion. Its interest lies in that it is possible to add a suggestion without having to modify the package that is concerned. Thus, all add-ons, plug-ins, and other extensions of a program can then appear in the list of suggestions related to the software. Although it has existed for several years, this last field is still largely ignored by programs such as <command>apt</command> or <command>synaptic</command>. Its purpose is for a suggestion made by the <literal>Enhances</literal> field to appear to the user in addition to the traditional suggestions — found in the <literal>Suggests</literal> field.
nb-NO: <literal>Enhances</literal>-feltet beskriver også et forslag, men i en annen sammenheng. Det ligger faktisk i den foreslåtte pakken, og ikke i den pakken som drar nytte av forslaget. Poenget ligger i at det er mulig å legge til et forslag uten å måtte modifisere den pakken forslaget gjelder. Dermed kan alle tillegg, innstikkmoduler og andre utvidelser av et program dukke opp i listen over forslag til programvaren. Selv om dette feltet har eksistert i flere år, er det fremdeles i stor grad ignorert av programmer som <command>apt</command> eller <command>synaptic</command>. Formålet med et forslag fra <literal>Enhances</literal>-feltet er å vises for brukeren i tillegg til de tradisjonelle forslagene fra <literal>Suggests</literal>-feltet.

en: <emphasis>DEBIAN POLICY</emphasis> <literal>Pre-Depends</literal>, a more demanding <literal>Depends</literal>
nb-NO: <emphasis>DEBIAN-RETNINGSLINJER</emphasis> <literal>Pre-Depends</literal>, en mer krevende <literal>Depends</literal>

en: <primary>package</primary><secondary>pre-dependency</secondary>
nb-NO: <primary>pakke</primary><secondary>forhånds-avhengighet</secondary>

en: <primary>pre-dependency</primary>
nb-NO: <primary>Før-avhengighet</primary>

en: <primary><filename>control</filename></primary><secondary><literal>Pre-Depends</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Pre-Depends</literal>, hodefelt</secondary>

en: “Pre-dependencies”, which are listed in the “<literal>Pre-Depends</literal>” field in the package headers, complete the normal dependencies; their syntax is identical. A normal dependency indicates that the package in question must be unpacked and configured before configuration of the package declaring the dependency. A pre-dependency stipulates that the package in question must be unpacked and configured before execution of the pre-installation script of the package declaring the pre-dependency, that is before its installation.
nb-NO: «Før-avhengigheter» som er listet i “<literal>Pre-Depends</literal>”-feltet i pakkehodet, utfyller de normale avhengighetene; syntaksen er lik. En normal avhengighet indikerer at den omtalte pakken det gjelder må pakkes ut og settes opp før oppsett av pakken som har erklært avhengigheten. En før-avhengighet krever at den omtalte pakken må pakkes ut og settes opp før kjøring av pre-installasjonskriptet til pakke som har erklært før-avhengigheten, det vil si før installasjon.

en: <primary>mailing lists</primary><secondary><email>debian-devel@lists.debian.org</email></secondary>
nb-NO: <primary>epostlister</primary><secondary><email>debian-devel@lists.debian.org</email></secondary>

en: Conflicts: the <literal>Conflicts</literal> field
nb-NO: Konflikter: <literal>Conflicts</literal>-feltet

en: <primary>conflicts</primary>
nb-NO: <primary>konflikter</primary>

en: <primary>package</primary><secondary>conflict</secondary>
nb-NO: <primary>pakke</primary><secondary>konflikt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Conflicts</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Conflicts</literal>, hodefelt</secondary>

en: The <literal>Conflicts</literal> field indicates when a package cannot be installed simultaneously with another. The most common reasons for this are that both packages include a file of the same name and path, or provide the same service on the same TCP port, or would hinder each other's operation.
nb-NO: <literal>Conflicts</literal>-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.

en: <command>dpkg</command> will refuse to install a package if it triggers a conflict with an already installed package, except if the new package specifies that it will “replace” the installed package, in which case <command>dpkg</command> will choose to replace the old package with the new one. <command>apt</command> always follows your instructions: if you choose to install a new package, it will automatically offer to uninstall the package that poses a problem.
nb-NO: <command>dpkg</command> 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 <command>dpkg</command> velge å erstatte den gamle pakken med den nye. <command>apt</command> følger alltid dine instruksjoner: Hvis du velger å installere en ny pakke, vil den automatisk tilby å avinstallere pakken som utgjør et problem.

en: Incompatibilities: the <literal>Breaks</literal> Field
nb-NO: Manglende samsvar: <literal>Breaks</literal>-feltet

en: <primary>incompatibilities</primary>
nb-NO: <primary>inkompatibiliteter</primary>

en: <primary>package</primary><secondary>incompatibility</secondary>
nb-NO: <primary>pakke</primary><secondary>inkompatibilitet</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Breaks</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Breaks</literal>, hodefelt</secondary>

en: The <literal>Breaks</literal> field has an effect similar to that of the <literal>Conflicts</literal> field, but with a special meaning. It signals that the installation of a package will “break” another package (or particular versions of it). In general, this incompatibility between two packages is transitory, and the <literal>Breaks</literal> relationship specifically refers to the incompatible versions.
nb-NO: <literal>Breaks</literal>-feltet har en effekt lik <literal>Conflicts</literal>-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 <literal>Breaks</literal>-forholdet refererer spesifikt til de inkompatible versjonene.

en: <command>dpkg</command> will refuse to install a package that breaks an already installed package, and <command>apt</command> will try to resolve the problem by updating the package that would be broken to a newer version (which is assumed to be fixed and, thus, compatible again).
nb-NO: <command>dpkg</command> vil avslå å installere en pakke som ødelegger for en allerede installert pakke, og <command>apt</command> 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).

en: This type of situation may occur in the case of updates without backwards compatibility: this is the case if the new version no longer functions with the older version, and causes a malfunction in another program without making special provisions. The <literal>Breaks</literal> field prevents the user from running into these problems.
nb-NO: 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. <literal>Breaks</literal>-feltet hindrer brukeren å komme inn i disse problemene.

en: Provided Items: the <literal>Provides</literal> Field
nb-NO: Tilbudte elementer: <literal>Provides</literal>-feltet

en: <primary><filename>control</filename></primary><secondary><literal>Provides</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Provides</literal>, hodefelt</secondary>

en: This field introduces the very interesting concept of a “virtual package”. It has many roles, but two are of particular importance. The first role consists in using a virtual package to associate a generic service with it (the package “provides” the service). The second indicates that a package completely replaces another, and that for this purpose it can also satisfy the dependencies that the other would satisfy. It is thus possible to create a substitution package without having to use the same package name.
nb-NO: 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 .

en: <emphasis>VOCABULARY</emphasis> Meta-package and virtual package
nb-NO: <emphasis>ORDFORRÅD</emphasis> Metapakke og virtuell pakke

en: <primary>package</primary><secondary>virtual package</secondary>
nb-NO: <primary>pakke</primary><secondary>virtuell pakke</secondary>

en: <primary>package</primary><secondary>meta-package</secondary>
nb-NO: <primary>pakke</primary><secondary>meta-pakke</secondary>

en: <primary>virtual package</primary>
nb-NO: <primary>virtuell pakke</primary>

en: It is essential to clearly distinguish meta-packages from virtual packages. The former are real packages (including real <filename>.deb</filename> files), whose only purpose is to express dependencies.
nb-NO: Det er viktig å skille klart metapakker fra virtuelle pakker. Det første er ekte pakker (medregnet virkelige <filename>.deb</filename>-filer), hvis eneste formål er å uttrykke avhengigheter.

en: Virtual packages, however, do not exist physically; they are only a means of identifying real packages based on common, logical criteria (service provided, compatibility with a standard program or a pre-existing package, etc.).
nb-NO: Virtuelle pakker derimot, eksisterer ikke fysisk, de er bare et hjelpemiddel til å identifisere virkelige pakker basert på felles, logiske kriterier (tjeneste levert, kompatibilitet med et standard program, eller en tidligere installert pakke, etc.).

en: Providing a “Service”
nb-NO: Tilby en «Tjeneste»

en: Let us discuss the first case in greater detail with an example: all mail servers, such as <emphasis role="pkg">postfix</emphasis> or <emphasis role="pkg">sendmail</emphasis> are said to “provide” the <emphasis role="pkg">mail-transport-agent</emphasis> virtual package. Thus, any package that needs this service to be functional (e.g. a mailing list manager, such as <emphasis role="pkg">smartlist</emphasis> or <emphasis role="pkg">sympa</emphasis>) simply states in its dependencies that it requires a <emphasis role="pkg">mail-transport-agent</emphasis> instead of specifying a large yet incomplete list of possible solutions (e.g. <command>postfix | sendmail | exim4 | …</command>). Furthermore, it is useless to install two mail servers on the same machine, which is why each of these packages declares a conflict with the <emphasis role="pkg">mail-transport-agent</emphasis> virtual package. A conflict between a package and itself is ignored by the system, but this technique will prohibit the installation of two mail servers side by side.
nb-NO: La oss diskutere det første tilfellet i større detalj med et eksempel: Alle e-posttjenere, for eksempel <emphasis role="pkg">postfix</emphasis> eller <emphasis role="pkg">sendmail</emphasis> sies å «tilby» den virtuelle <emphasis role="pkg">mail-transport-agent</emphasis>-pakken. Dermed behøer alle pakker som trenger denne tjenesten for å være funksjonelle (for eksempel en e-postlistebehandler, som <emphasis role="pkg">smartlist</emphasis>, eller <emphasis role="pkg">sympa</emphasis>) kun å oppgi i sine avhengigheter at det krever en <emphasis role="pkg">mail-transport-agent</emphasis> i stedet for å angi en stor og ufullstendig liste over mulige løsninger (f.eks. <command>postfix | sendmail | exim4 | …</command>). 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 <emphasis role="pkg">mail-transport-agent</emphasis>. 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.

en: <emphasis>DEBIAN POLICY</emphasis> List of virtual packages
nb-NO: <emphasis>DEBIAN-RETNINGSLINJER</emphasis> Liste over virtuelle pakker

en: For virtual packages to be useful, everyone must agree on their name. This is why they are standardized in the Debian Policy. The list includes among others <emphasis role="pkg">mail-transport-agent</emphasis> for mail servers, <emphasis role="pkg">c-compiler</emphasis> for C programming language compilers, <emphasis role="pkg">www-browser</emphasis> for web browsers, <emphasis role="pkg">httpd</emphasis> for web servers, <emphasis role="pkg">ftp-server</emphasis> for FTP servers, <emphasis role="pkg">x-terminal-emulator</emphasis> for terminal emulators in graphical mode (<command>xterm</command>), and <emphasis role="pkg">x-window-manager</emphasis> for window managers.
nb-NO: Skal virtuelle pakker være nyttige, må alle være enige om hva de skal hete. Derfor er de standardisert i Debian-retningslinjene. Listen omfatter blant annet <emphasis role="pkg">mail-transport-agent</emphasis> for posttjenere, <emphasis role="pkg">c-compiler</emphasis> for C-kompilatorer, <emphasis role="pkg">www-browser</emphasis> for nettlesere, <emphasis role="pkg">httpd</emphasis> for nettjenere, <emphasis role="pkg">ftp-server</emphasis> for FTP-tjenere, <emphasis role="pkg">x-terminal-emulator</emphasis> for grafiske terminalemulatorer (<command>xterm</command>), og <emphasis role="pkg">x-window-manager</emphasis> for vindushåndterere.

en: Interchangeability with Another Package
nb-NO: Utbyttbarheten med en annen pakke

en: Use of a <literal>Provides</literal> field in order to not break dependencies
nb-NO: Bruk av et <literal>Provides</literal>-felt for å ikke bryte avhengigheter

en: This feature is very useful, since it is never possible to anticipate the vagaries of development, and it is necessary to be able to adjust to renaming, and other automatic replacement, of obsolete software.
nb-NO: 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.

en: <emphasis>BACK TO BASICS</emphasis> Perl, a programming language
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Perl, et programmeringsspråk

en: Perl (Practical Extraction and Report Language) is a very popular programming language. It has many ready-to-use modules that cover a vast spectrum of applications, and that are distributed by the <acronym>CPAN</acronym> (Comprehensive Perl Archive Network) servers, an exhaustive network of Perl packages. <ulink type="block" url="https://www.perl.org/" /> <ulink type="block" url="https://www.cpan.org/" />
nb-NO: Perl (Practical Extraction and Report Language) er et svært populært programmeringsspråk . Det har mange ferdige moduler som dekker et stort spekter av bruksområder, og som distribueres av <acronym>CPAN</acronym> (Comprehensive Perl Archive Network), et uttømmelig nettverk av Perl-pakker. <ulink type="block" url="https://www.perl.org/" /> <ulink type="block" url="https://www.cpan.org/" />

en: Since it is an interpreted language, a program written in Perl does not require compilation prior to execution. This is why they are called “Perl scripts”.
nb-NO: Siden det er et tolket språk, kreves ikke et program skrevet i Perl kompilering før kjøring. Det er derfor de kalles «Perl-skript».

en: Past Limitations
nb-NO: Tidligere begrensninger

en: Replacing Files: The <literal>Replaces</literal> Field
nb-NO: Erstatte filer: <literal>Replaces</literal>-feltet

en: <primary>replacement</primary>
nb-NO: <primary>erstatning</primary>

en: <primary>package</primary><secondary>replacement</secondary>
nb-NO: <primary>pakke</primary><secondary>erstatning</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Replaces</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Replaces</literal>, hodefelt</secondary>

en: The use of this field is justified when package names change or when a package is included in another. This also happens when the maintainer decides to distribute files differently among various binary packages produced from the same source package: a replaced file no longer belongs to the old package, but only to the new one.
nb-NO: 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.

en: If all of the files in an installed package have been replaced, the package is considered to be removed. Finally, this field also encourages <command>dpkg</command> to remove the replaced package where there is a conflict.
nb-NO: Hvis alle filene i en installert pakke er blitt erstattet, så vurderes det å fjerne pakken. Sist, men ikke minst, så oppmundrer dette feltet også <command>dpkg</command> til å fjerne den erstattede pakken der det er en konflikt.

en: <emphasis>GOING FURTHER</emphasis> The <literal>Tag</literal> field
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> <literal>Tag</literal>-feltet

en: Configuration Scripts
nb-NO: Oppsettsskript

en: <emphasis>GOING FURTHER</emphasis> <command>dpkg</command>'s database
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Databasen til <command>dpkg</command>

en: All of the configuration scripts for installed packages are stored in the <filename>/var/lib/dpkg/info/</filename> directory, in the form of a file prefixed with the package's name. This directory also includes a file with the <filename>.list</filename> extension for each package, containing the list of files that belong to that package.
nb-NO: Alle oppsettsskript for installerte pakker blir lagret i katalogen <filename>/var/lib/dpkg/info/</filename> i form av en fil med pakkenavnet som prefiks. Denne katalogen inneholder også en fil med <filename>.list</filename>-endelse for hver pakke, med en liste med filer som hører til den pakken.

en: The <filename>/var/lib/dpkg/status</filename> file contains a series of data blocks (in the format of the famous mail headers, RFC 2822) describing the status of each package. The information from the <filename>control</filename> file of the installed packages is also replicated there.
nb-NO: <filename>/var/lib/dpkg/status</filename>-filen inneholder en serie datablokker (i formatet til de berømte eposthodene, RFC 2822) som beskriver status for hver pakke. Informasjonen fra <filename>control</filename>-filen for de installerte pakkene er også gjentatt der.

en: In general, the <filename>preinst</filename> script is executed prior to installation of the package, while <filename>postinst</filename> follows it. Likewise, <filename>prerm</filename> is invoked before removal of a package and <filename>postrm</filename> afterwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.
nb-NO: Generelt er <filename>preinst</filename>-skriptet utført før installasjonen av pakken, mens <filename>postinst</filename> følger etter dette. På samme måte er <filename>prerm</filename> aktivert før en pakke fjernes og <filename>postrm</filename> 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.

en: <emphasis>CAUTION</emphasis> Symbolic names of the scripts
nb-NO: <emphasis>VÆR VARSOM</emphasis> Symbolske skript-navn

en: The sequences described in this section call configuration scripts by specific names, such as <command>old-prerm</command> or <command>new-postinst</command>. They are, respectively, the <command>prerm</command> script contained in the old version of the package (installed before the update) and the <command>postinst</command> script contained in the new version (installed by the update).
nb-NO: Sekvensene beskrevet i denne seksjonen omtaler oppsettsskript med spesifikke navn, for eksempel <command>gammel-prerm</command>, eller <command>ny-postinst</command>. De er, respektivt, <command>prerm</command>-skriptet fra den gamle pakkeversjonen (installert før oppdateringen), og <command>postinst</command>-skriptet fra den nye versjonen (installert av oppdateringen).

en: <emphasis>TIP</emphasis> State diagrams
nb-NO: <emphasis>TIPS</emphasis> Statusdiagrammer

en: Manoj Srivastava and Margarita Manterola made the following diagrams explaining how the configuration scripts are called by <command>dpkg</command>. <ulink type="block" url="https://people.debian.org/~srivasta/MaintainerScripts.html" /> <ulink type="block" url="https://www.debian.org/doc/debian-policy/ap-flowcharts.html" />
nb-NO: Manoj Srivastava og Margarita Manterola laget følgende diagrammer som forklarte hvordan oppsettskriptene kalles opp av <command>dpkg</command>. <ulink type="block" url="https://people.debian.org/~srivasta/MaintainerScripts.html" /> <ulink type="block" url="https://www.debian.org/doc/debian-policy/ap-flowcharts.html" />

en: Installation and Upgrade
nb-NO: Installasjon og oppgradering

en: <primary><command>dpkg</command></primary><secondary>internal operation</secondary>
nb-NO: <primary><command>dpkg</command></primary><secondary>intern oppførsel</secondary>

en: <primary>package</primary><secondary>installation</secondary>
nb-NO: <primary>pakke</primary><secondary>installasjon</secondary>

en: During the initial installation and for each upgrade of a package, <command>dpkg</command> calls the so called <emphasis>maintainer scripts</emphasis> such as the <command>prerm</command> or <command>preinst</command> scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by <literal>new-</literal> are the scripts from the new version of a package being installed or upgraded to. Script names preceded by <literal>old-</literal> are the scripts from the old version of a package that is being upgraded from.
nb-NO: I løpet av innledende installasjon og for hver oppgradering av en pakke, kaller <command>dpkg</command> de såkalte <emphasis>vedlikeholderskriptene</emphasis>, som f.eks. <command>prerm</command> eller <command>preinst</command>-skriptene. Disse kan utføre ytterligere handlinger i forskjellige stadier av en pakkes livssyklus. Skriptnavn som innledes med «<literal>new-</literal>» er skript fra den nye versjonen av en pakke som blir installert eller det blir oppgradert til. Skriptnavn innledet av «<literal>old-</literal>» er skript fra den gamle versjonen av pakken det blir oppgradert fra.

en: Here is what happens during an installation (or an update). The <replaceable>old-version</replaceable>, <replaceable>new-version</replaceable> and <replaceable>last-version-configured</replaceable> arguments are placeholders for the actual (old and new) version numbers of the package:
nb-NO: Dette skjer i løpet av en installasjon (eller en oppgradering). <replaceable>old-version</replaceable>, <replaceable>new-version</replaceable> og <replaceable>last-version-configured</replaceable>-argumentene er plassholdere for de faktiske (gamle og nye) versjonsnumrene for pakken:

en: The new package files are then unpacked. If a file already exists, it is replaced, but a backup copy is temporarily made.
nb-NO: De nye pakkefiler er så pakket ut. Hvis en fil allerede finnes, blir den erstattet, men en sikkerhetskopi lages midlertidig.

en: <command>dpkg</command> updates all of the internal data (file list, configuration scripts, etc.) and removes the backups of the replaced files. This is the point of no return: <command>dpkg</command> no longer has access to all of the elements necessary to return to the previous state.
nb-NO: <command>dpkg</command> oppdaterer alle interne data (filliste, oppsettsskript, etc.) og fjerner sikkerhetskopier av de erstattede filene. Det er det ingen vei tilbake: <command>dpkg</command> har ikke lenger tilgang til alle de elementer som er nødvendige for å gå tilbake til slik det var før.

en: <command>dpkg</command> will update the configuration files, asking the user to decide if it is unable to automatically manage this task. The details of this procedure are discussed in <xref linkend="sect.conffiles" />.
nb-NO: <command>dpkg</command> vil oppdatere oppsettsfilene, be brukeren om å avgjøre om den ikke kan håndtere denne oppgaven automatisk. Detaljene ved denne fremgangsmåten er omtalt i <xref linkend="sect.conffiles" />.

en: Package Removal
nb-NO: Fjerning av pakke

en: <primary>package</primary><secondary>removal</secondary>
nb-NO: <primary>pakke</primary><secondary>fjerne</secondary>

en: The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:
nb-NO: Stegene for å fjerne en pakke tilsvarer dem for installasjonsstegene. Hovedforskjellen er at fjerningsskriptene for pakken påkalles:

en: <emphasis>VOCABULARY</emphasis> Purge, a complete removal
nb-NO: <emphasis>ORDFORRÅD</emphasis> Opprydding, en komplett fjerning

en: <primary>purging a package</primary>
nb-NO: <primary>fullstendig fjerning av en pakke</primary>

en: <primary>package</primary><secondary>purge</secondary>
nb-NO: <primary>pakke</primary><secondary>slette helt</secondary>

en: When a Debian package is removed, the configuration files are retained in order to facilitate possible re-installation. Likewise, the data generated by a daemon (such as the content of an LDAP server directory, or the content of a database for an SQL server) are usually retained.
nb-NO: Når en Debian-pakke er fjernet, blir oppsettsfilene beholdt for å tilrettelegge for eventuell re-installasjon. På samme måte blir data generert av en bakgrunnsprosess vanligvis beholdt (for eksempel innholdet i en LDAP-tjenerkatalog, eller innholdet i en database for en SQL-tjener).

en: To remove all data associated with a package, it is necessary to “purge” the package with the command, <command>dpkg -P <replaceable>package</replaceable></command>, <command>apt-get remove --purge <replaceable>package</replaceable></command> or <command>aptitude purge <replaceable>package</replaceable></command>.
nb-NO: For å fjerne alle data knyttet til en pakke må man «renske» pakken med kommandoen <command>dpkg -P <replaceable>package</replaceable></command>, <command>apt-get remove --purge <replaceable>package</replaceable></command> eller <command>aptitude purge <replaceable>package</replaceable></command>.

en: Given the definitive nature of such data removals, a purge should not be taken lightly.
nb-NO: Gitt den endelige virkningen av slik fjerning av data, bør en ikke ta lett på oppryddingen.

en: <primary><filename>config</filename>, <command>debconf</command> script</primary>
nb-NO: <primary><filename>config</filename>, <command>debconf</command> skript</primary>

en: The four scripts detailed above are complemented by a <filename>config</filename> script, provided by packages using <command>debconf</command> to acquire information from the user for configuration. During installation, this script defines in detail the questions asked by <command>debconf</command>. The responses are recorded in the <command>debconf</command> database for future reference. The script is generally executed by <command>apt</command> prior to installing packages one by one in order to group all the questions and ask them all to the user at the beginning of the process. The pre- and post-installation scripts can then use this information to operate according to the user's wishes.
nb-NO: De fire skriptene detaljert ovenfor er supplert med et <filename>config</filename> skript, fra pakker som bruker <command>debconf</command> for å få informasjon fra brukeren inn i oppsettet. Under installasjonen definerer dette skriptet i detalj de spørsmålene som stilles fra <command>debconf</command>. Svarene registreres i <command>debconf</command>-databasen for fremtidig bruk. Skriptet er generelt utført av <command>apt</command> 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.

en: <emphasis>TOOL</emphasis> <command>debconf</command>
nb-NO: <emphasis>VERKTØY</emphasis> <command>debconf</command>

en: <command>debconf</command> was created to resolve a recurring problem in Debian. All Debian packages unable to function without a minimum of configuration used to ask questions with calls to the <command>echo</command> and <command>read</command> commands in <filename>postinst</filename> shell scripts (and other similar scripts). But this also means that during a large installation or update the user must stay with their computer to respond to various questions that may arise at any time. These manual interactions have now been almost entirely dispensed with, thanks to the <command>debconf</command> tool.
nb-NO: <command>debconf</command> ble opprettet for å løse et tilbakevendende problem i Debian. Alle Debian-pakker som ikke virket uten et minimum av oppsett, pleide å stille spørsmål ved bruk av <command>echo</command> og <command>read</command> kommandoer i <filename>postinst</filename>-skript (og andre tilsvarende skript). Men dette betød også at, under en stor installasjon eller oppdatering måtte brukeren sitte ved datamaskinen sin for å svare på ulike spørsmål som når som helst kan komme. Disse manuelle inngrepene er nå nesten helt avviklet, takket være <command>debconf</command>-verktøyet.

en: <command>debconf</command> has many interesting features: it requires the developer to specify user interaction; it allows localization of all the strings displayed to users (all translations are stored in the <filename>templates</filename> file describing the interactions); it has different frontends to display the questions to the user (text mode, graphical mode, non-interactive); and it allows creation of a central database of responses to share the same configuration with several computers... but the most important is that it is now possible to present all of the questions in a row to the user, prior to starting a long installation or update process. The user can go about their business while the system handles the installation on its own, without having to stay there staring at the screen waiting for questions.
nb-NO: <command>debconf</command> har mange interessante funksjoner. Den krever at utvikleren spesifiserer brukermedvirkning; den tillater regionale tilpasninger av alle strengene som vises til brukere (alle oversettelser blir lagret i <filename>templates</filename>-filen som beskriver medvirkningen); den har ulike grensesnitt for å vise spørsmålene til brukeren (tekstmodus, grafisk modus, ikke-interaktiv), og den tillater opprettelsen av en sentral database med svar for å dele samme oppsett mellom datamaskiner ... men det viktigste er at det nå er mulig å presentere alle spørsmålene i en rekke for brukeren, før du starter en lang installasjons- eller oppdateringsprosess. Brukeren kan fortsette med sin virksomhet, mens systemet tar seg av installasjonen på egen hånd, uten å måtte være der og stirre på skjermen og vente på spørsmål.

en: Checksums, List of Configuration Files, et al.
nb-NO: Sjekksummer, Liste med oppsettfiler, med mere

en: <primary>checksums</primary>
nb-NO: <primary>sjekksummer</primary>

en: In addition to the maintainer scripts and control data already mentioned in the previous sections, the <filename>control.tar.gz</filename> archive of a Debian package may contain other interesting files.
nb-NO: I tillegg til vedlikeholderskript og kontrolldata som allerede er nevnte i de forrige delene, kan <filename>control.tar.gz</filename>-arkivet av en Debian-pakke inneholde andre interessante filer.

en: In effect, in this situation, <command>dpkg</command> behaves as intelligently as possible: if the standard configuration file has not changed between the two versions, it does nothing. If, however, the file has changed, it will try to update this file. Two cases are possible: either the administrator has not touched this configuration file, in which case <command>dpkg</command> automatically installs the new version; or the file has been modified, in which case <command>dpkg</command> asks the administrator which version they wish to use (the old one with modifications, or the new one provided with the package). To assist in making this decision, <command>dpkg</command> offers to display a “<command>diff</command>” that shows the difference between the two versions. If the user chooses to retain the old version, the new one will be stored in the same location in a file with the <filename>.dpkg-dist</filename> suffix. If the user chooses the new version, the old one is retained in a file with the <filename>.dpkg-old</filename> suffix. Another available action consists of momentarily interrupting <command>dpkg</command> to edit the file and attempt to re-instate the relevant modifications (previously identified with <command>diff</command>).
nb-NO: I praksis oppfører <command>dpkg</command> 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 <command>dpkg</command> automatisk den nye versjonen, eller så er filen endret. I så tilfelle spør <command>dpkg</command> 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 <command>dpkg</command> å vise en «<command>diff</command>» 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 <filename>.dpkg-dist</filename>-ending. Hvis brukeren velger den nye versjonen, blir den gamle beholdt i en fil med <filename>.dpkg-old</filename>-endingen. En annen tilgjengelig handling er å straks avbryte <command>dpkg</command> for å redigere filen og forsøke å sette inn igjen de relevante endringene (tidligere identifisert med <command>diff</command>).

en: <emphasis>GOING FURTHER</emphasis> Force dpkg to ask configuration file questions
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Tving dpkg til å stille oppsettfilspørsmål

en: The <command>--force-confask</command> option requires <command>dpkg</command> to display the questions about the configuration files, even in cases where they would not normally be necessary. Thus, when reinstalling a package with this option, <command>dpkg</command> will ask the questions again for all of the configuration files modified or deleted by the administrator. This is very convenient, especially for reinstalling the original configuration file if it has been deleted and no other copy is available: a normal re-installation won't work, because <command>dpkg</command> considers removal as a form of legitimate modification, and, thus, doesn't install the desired configuration file.
nb-NO: <command>--force-confask</command>-valget krever at <command>dpkg</command> viser spørsmålene om oppsettsfilene, selv i tilfeller hvor det normalt ikke ville være nødvendig. Så når du installerer en pakke med dette alternativet, vil <command>dpkg</command> stille spørsmålene på nytt for alle oppsettsfiler som administrator har endret eller slettet. Dette er veldig praktisk, spesielt for å installere den opprinnelige oppsettsfilen hvis den har blitt slettet, og ingen annen kopi er tilgjengelig: En normal re-installasjon vil ikke fungere, fordi <command>dpkg</command> ser fjerning som en form for legitim endring, og dermed ikke installerer den filen du ønsker.

en: <emphasis>GOING FURTHER</emphasis> Avoiding the configuration file questions
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Hvordan unngå oppsettsfilspørsmålene

en: <command>dpkg</command> handles configuration file updates, but, while doing so, regularly interrupts its work to ask for input from the administrator. This makes it less than enjoyable for those who wish to run updates in a non-interactive manner. This is why this program offers options that allow the system to respond automatically according to the same logic: <command>--force-confold</command> retains the old version of the file; <command>--force-confnew</command> will use the new version of the file (these choices are respected, even if the file has not been changed by the administrator, which only rarely has the desired effect). Adding the <command>--force-confdef</command> option tells <command>dpkg</command> to decide by itself when possible (in other words, when the original configuration file has not been touched), and only uses <command>--force-confnew</command> or <command>--force-confold</command> for other cases.
nb-NO: <command>dpkg</command> håndterer oppsettsfiloppdateringer, men vil avbryte arbeidet regelmessig mens det gjøres for å få innspill fra administrator. Dette gjør det mindre trivelig for dem som ønsker å kjøre oppdateringer ikke-interaktivt. Dette er grunnen til at dette programmet tilbyr alternativer som gjør at systemet kan respondere automatisk etter samme logikk: <command>--force-confold</command> beholder den gamle versjonen av filen; <command>--force-confnew</command> vil bruke den nye versjonen av filen (disse valgene blir respektert, selv om filen ikke har blitt endret av administratoren, som bare sjelden har den ønskede effekten). Ved å legge til <command>--force-confdef</command>-valget ber en <command>dpkg</command> om å bestemme selv når det er mulig (med andre ord, når den opprinnelige oppsettsfilen ikke har blitt berørt), og bruker bare <command>--force-confnew</command> eller <command>--force-confold</command> i andre tilfeller.

en: These options apply to <command>dpkg</command> and are explained in detail in <citerefentry><refentrytitle>dpkg</refentrytitle><manvolnum>1</manvolnum></citerefentry> or <command>dpkg --force-help</command>, but most of the time the administrator will work directly with the <command>aptitude</command> or <command>apt</command> programs. It is, thus, necessary to know the syntax used to indicate the options to pass to the <command>dpkg</command> command (their command line interfaces are very similar).
nb-NO: Disse alternativene gjelder for <command>dpkg</command> og er forklart i detalj i <citerefentry><refentrytitle>dpkg</refentrytitle><manvolnum>1</manvolnum></citerefentry> eller <command>dpkg --force-help</command>, men mesteparten av tiden vil administratoren arbeide direkte med programmene <command>aptitude</command> eller <command>apt</command>. Det er derfor nødvendig å vite syntaksen som brukes til å angi alternativene som sendes til <command>dpkg</command>-kommandoen (kommandolinjegrensesnittene deres er svært like).

en: Including this option in the configuration file means that it will also be used in a graphical interface such as <command>aptitude</command>.
nb-NO: Å legge inn dette valget i oppsettsfilen, betyr at det også vil bli brukt i det grafiske brukergrensesnittet, slik som <command>aptitude</command>.

en: The control archive frequently contains other files as well, like <filename>triggers</filename>, <filename>shlibs</filename>, or <filename>symbols</filename>. These files are well described in <citerefentry><refentrytitle>deb-triggers</refentrytitle><manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>deb-shlibs</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and <citerefentry><refentrytitle>deb-symbols</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
nb-NO: Kontrollarkivet inneholder ofte også andre filer, som <filename>triggers</filename>, <filename>shlibs</filename>, eller <filename>symbols</filename>. Disse er godt beskrevet i <citerefentry><refentrytitle>deb-triggers</refentrytitle><manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>deb-shlibs</refentrytitle><manvolnum>5</manvolnum></citerefentry>, og <citerefentry><refentrytitle>deb-symbols</refentrytitle><manvolnum>5</manvolnum></citerefentry>.

en: Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in <ulink url="https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/doc/triggers.txt"><filename>/usr/share/doc/dpkg/triggers.txt.gz</filename></ulink>.
nb-NO: 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 <ulink url="https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/doc/triggers.txt"><filename>/usr/share/doc/dpkg/triggers.txt.gz</filename></ulink>.

en: The <filename>shlibs</filename> system is an older and simpler alternative to the <filename>symbols</filename> system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer <filename>symbols</filename> system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.
nb-NO: <filename>shlibs</filename>-er et eldre og enklere alternativ til <filename>symbols</filename>-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 <filename>symbols</filename>-systemet tillater definering av avhengigheten ved å istedenfor spore symbolene, og når de har blitt introdusert eller endret i biblioteket.

en: Structure of a Source Package
nb-NO: Kildepakkens struktur

en: <primary>package</primary><secondary>source package</secondary>
nb-NO: <primary>pakke</primary><secondary>kildepakke</secondary>

en: <primary>source package</primary>
nb-NO: <primary>kildepakke</primary>

en: <primary>DSC file</primary>
nb-NO: <primary>DSC-fil</primary>

en: A source package is usually comprised of three files, a <filename>.dsc</filename>, a <filename>.orig.tar.gz</filename>, and a <filename>.debian.tar.xz</filename> (or <filename>.diff.gz</filename>). They allow creation of binary packages (<filename>.deb</filename> files described above) from the source code files of the program, which are written in a programming language.
nb-NO: En kildepakke består vanligvis av tre filer: En <filename>.dsc</filename>, en <filename>.orig.tar.gz</filename>, og en <filename>.debian.tar.xz</filename> (eller <filename>.diff.gz</filename>). De tillater at det lages binære pakker (<filename>.deb</filename> filer beskrevet ovenfor) fra programmets kildekodefiler skrevet i et programmeringsspråk.

en: The <filename>.dsc</filename> (Debian Source Control) file is a short text file containing an RFC 2822 header (just like the <filename>control</filename> file studied in <xref linkend="sect.control" />) which describes the source package and indicates which other files are part thereof. It is signed by its maintainer, which guarantees authenticity. See <xref linkend="sect.package-authentication" /> for further details on this subject.
nb-NO: <filename>.dsc</filename> (Debian Source Control)-filen er en tekstfil som inneholder et RFC 2822 filhode (lik <filename>control</filename>-filen gjennomgått i <xref linkend="sect.control" />) som beskriver kildepakken og angir hvilke andre filer som inngår. Det er signert av sin vedlikeholder, som garanterer for ektheten. Se <xref linkend="sect.package-authentication" /> for flere detaljer om dette temaet.

en: A <filename>.dsc</filename> file
nb-NO: En <filename>.dsc</filename>-fil

en: <primary>package</primary><secondary>build dependencies</secondary>
nb-NO: <primary>pakke</primary><secondary>byggavhengigheter</secondary>

en: Note that the source package also has dependencies (<literal>Build-Depends</literal>) completely distinct from those of binary packages, since they indicate tools required to compile the software in question and construct its binary package.
nb-NO: Merk at kildepakken også egne avhengigheter (<literal>Build-Depends</literal>) helt uavhengig av de binære pakkenes, siden de forklarer hvilke verktøy som kreves til å kompilere og lage binærpakken for programvaren det gjelder.

en: <emphasis>CAUTION</emphasis> Distinct namespaces
nb-NO: <emphasis>VÆR VARSOM</emphasis> Ulike navnerom

en: It is important to note here that there is no required correspondence between the name of the source package and that of the binary package(s) that it generates. It is easy enough to understand if you know that each source package may generate several binary packages. This is why the <filename>.dsc</filename> file has the <literal>Source</literal> and <literal>Binary</literal> fields to explicitly name the source package and store the list of binary packages that it generates.
nb-NO: Her er det viktig å merke seg at det ikke kreves samsvar mellom navnet til kildepakken og på den eller de binære pakkene som den genererer. Det er lett nok å forstå hvis du vet at hver kildepakke kan generere flere binære pakker. Dette er grunnen til at <filename>.dsc</filename>-filen har <literal>Source</literal> og <literal>Binary</literal>-felt til eksplisitt å navngi kildepakken og lagre listen med binærpakkene som den genererer.

en: <emphasis>CULTURE</emphasis> Why divide into several packages
nb-NO: <emphasis>KULTUR</emphasis> Hvorfor dele opp i flere pakker

en: Quite frequently, a source package (for a given software) can generate several binary packages. The split is justified by the possibility to use (parts of) the software in different contexts. Consider a shared library, it may be installed to make an application work (for example, <emphasis role="pkg">libc6</emphasis>), or it can be installed to develop a new program (<emphasis role="pkg">libc6-dev</emphasis> will then be the correct package). We find the same logic for client/server services where we want to install the server part on one machine and the client part on others (this is the case, for example, of <emphasis role="pkg">openssh-server</emphasis> and <emphasis role="pkg">openssh-client</emphasis>).
nb-NO: Ganske ofte kan en kildepakke (for en gitt programvare) generere flere binære pakker. Oppsplittingen er begrunnet i muligheten til å bruke (deler av) programvaren i ulike sammenhenger. Betraktet som et delt bibliotek, kan den være installert for å få et program til å virke (for eksempel, <emphasis role="pkg">libc6</emphasis>), eller den kan installeres for å utvikle et nytt program (<emphasis role="pkg">libc6-dev</emphasis> vil da være den riktige pakken). Vi finner den samme logikken for klient/tjener-tjenester der vi ønsker å installere tjenerdelen på en maskin og klientdelen på andre (dette er tilfellet, for eksempel for <emphasis role="pkg">openssh-server</emphasis> og <emphasis role="pkg">openssh-client</emphasis>).

en: <emphasis>PERSPECTIVE</emphasis> Different source package formats
nb-NO: <emphasis>PERSPEKTIV</emphasis> Ulike kilde-pakkeformater

en: <primary>source package</primary><secondary>format</secondary>
nb-NO: <primary>kildepakke</primary><secondary>format</secondary>

en: Originally there was only one source package format. This is the <literal>1.0</literal> format, which associates an <filename>.orig.tar.gz</filename> archive to a <filename>.diff.gz</filename> “debianization” patch (there is also a variant, consisting of a single <filename>.tar.gz</filename> archive, which is automatically used if no <filename>.orig.tar.gz</filename> is available).
nb-NO: Originalt var det bare ett kildepakkeformat. Det er <literal>1.0</literal>-formatet, som kobler en <filename>.orig.tar.gz</filename>-tarball med en <filename>.diff.gz</filename>-«debianiserings»-patch (det er også en variant, som består av et enkelt <filename>.tar.gz</filename>-arkiv, som brukes automatisk hvis ikke <filename>.orig.tar.gz</filename> er tilgjengelig).

en: Since Debian 6 <emphasis role="distribution">Squeeze</emphasis>, Debian developers have the option to use new formats that correct many problems of the historical format. Format <literal>3.0 (quilt)</literal> can combine multiple upstream archives in the same source package: in addition to the usual <filename>.orig.tar.gz</filename>, supplementary <filename>.orig-<replaceable>component</replaceable>.tar.gz</filename> archives can be included. This is useful with software that is distributed in several upstream components but for which a single source package is desired. These archives can also be compressed with <command>xz</command> rather than <command>gzip</command>, which saves disk space and network resources. Finally, the monolithic patch, <filename>.diff.gz</filename> is replaced by a <filename>.debian.tar.xz</filename> archive containing the compiling instructions and a set of upstream patches contributed by the package maintainer. These last are recorded in a format compatible with <command>quilt</command> — a tool that facilitates the management of a series of patches.
nb-NO: Etter Debian 6 <emphasis role="distribution">Squeeze</emphasis>, har Debian-utviklere mulighet til å bruke nye formater som korrigerer for mange problemer i det gamle formatet. Formatet <literal>3.0 (quilt)</literal> kan kombinere ulike oppstrøms arkiver i den samme kildepakken: I tillegg til det vanlige <filename>.orig.tar.gz</filename>, kan i tillegg <filename>.orig-<replaceable>komponent</replaceable>.tar.gz</filename>-arkiver tas med. Dette er nyttig med programvare som er fordelt på flere oppstrøms komponenter, men hvor en enkelt kildepakke trengs. Disse arkivene kan også komprimeres med <command>xz</command>, i stedet for <command>gzip</command>, som sparer lagringsplass og nettverksressurser. Til slutt, den monolittiske endringslisten,<filename>.diff.gz</filename>, er erstattet av en <filename>.debian.tar.xz</filename>-pakke med kompileringsinstruksjonene, og et sett oppstrøm endringer pakkevedlikeholderen har bidratt med. Disse siste er lagt inn i et format som er kompatibelt med <command>quilt</command> - et verktøy som forenkler håndteringen av en samling endringer.

en: The <filename>.orig.tar.gz</filename> file is an archive containing the source code as provided by the original developer. Debian package maintainers are asked to not modify this archive in order to be able to easily check the origin and integrity of the file (by simple comparison with a checksum) and to respect the wishes of some authors.
nb-NO: <filename>.orig.tar.gz</filename>-filen er et arkiv som inneholder kildekoden som er stilt til disposisjon av den opprinnelige utvikleren. Debianpakkevedlikeholdere blir bedt om å ikke endre dette arkivet for å være i stand til enkelt å sjekke opprinnelsen og integriteten til filen (ved enkel sammenligning av sjekksum), og for å respektere ønskene til noen forfattere.

en: <emphasis>TOOL</emphasis> Decompressing a source package
nb-NO: <emphasis>VERKTØY</emphasis> Å pakke ut en kildepakke

en: <primary>decompressing, source package</primary>
nb-NO: <primary>dekomprimering, kildepakke</primary>

en: <primary>uncompressing, source package</primary>
nb-NO: <primary>pakke ut, kildepakke</primary>

en: <primary>unpacking</primary><secondary>source package</secondary>
nb-NO: <primary>pakke ut</primary><secondary>kildepakke</secondary>

en: <primary>source package</primary><secondary>unpacking</secondary>
nb-NO: <primary>kildepakke</primary><secondary>utpakking</secondary>

en: If you have a source package, you can use the <command>dpkg-source</command> command (from the <emphasis role="pkg">dpkg-dev</emphasis> package) to decompress it:
nb-NO: Hvis du har en kildepakke, kan du bruke <command>dpkg-source</command>-kommandoen (fra <emphasis role="pkg">dpkg-dev</emphasis>-pakken) for å pakke den ut:

en: You can also use <command>apt</command> to download a source package and unpack it right away. It requires that the appropriate <literal>deb-src</literal> lines be present in the <filename>/etc/apt/sources.list</filename> file, however (for further details, see <xref linkend="sect.apt-sources.list" />). These are used to list the “sources” of source packages (meaning the servers on which a group of source packages are hosted).
nb-NO: Du kan også bruke <command>apt</command> for å laste ned en kildepakke og pakke den opp med en gang. Det krever at de passende <literal>deb-src</literal>-linjer er til stede i <filename>/etc/apt/sources.list</filename>-filen, (for flere detaljer se gjerne <xref linkend="sect.apt-sources.list" />). Disse brukes til å liste «kildene» til kildepakkene (som betyr tjenere der en gruppe kildepakker ligger).

en: Usage within Debian
nb-NO: Bruk i Debian

en: <emphasis>GOING FURTHER</emphasis> Source only maintainer uploads
nb-NO: <emphasis> FOR VIDEREKOMMENDE</emphasis> Kun kildeopplasting fra vedlikeholder

en: Manipulating Packages with <command>dpkg</command>
nb-NO: Håndtere pakker med <command>dpkg</command>

en: <command>dpkg</command> is the base command for handling Debian packages on the system. If you have <filename>.deb</filename> packages, it is <command>dpkg</command> that allows installation or analysis of their contents. But this program only has a partial view of the Debian universe: it knows what is installed on the system, and whatever it is given on the command line, but knows nothing of the other available packages. As such, it will fail if a dependency is not met. Tools such as <command>apt</command> and <command>aptitude</command>, on the contrary, will create a list of dependencies to install everything as automatically as possible.
nb-NO: <command>dpkg</command> er basiskommandoen for å behandle Debian-pakker på systemet. Hvis du har <filename>.deb</filename>-pakker, er det <command>dpkg</command> som tillater installasjon eller analyse av innholdet deres. Men dette programmet har bare en delvis oversikt over Debian-universet. Det vet hva som er installert på systemet, og hva det er gitt på kommandolinjen, men vet ingenting om andre tilgjengelige pakker. Den vil mislykkes hvis en avhengighet ikke er oppfylt. Verktøy som <command>apt</command> og <command>aptitude</command>, vil derimot lage en liste over avhengigheter for å kunne installere alt så automatisk som mulig.

en: <emphasis>NOTE</emphasis> <command>dpkg</command> or <command>apt</command>?
nb-NO: <emphasis>MERK</emphasis> <command>dpkg</command> eller <command>apt</command>?

en: <command>dpkg</command> should be seen as a system tool (backend), and <command>apt</command> as a tool closer to the user, which overcomes the limitations of the former. These tools work together, each one with its particularities, suited to specific tasks.
nb-NO: <command>dpkg</command> skal sees som et systemverktøy (bakstykke), og <command>apt</command> som et verktøy nærmere brukeren, som overvinner begrensningene av det første. Disse verktøyene fungerer sammen, hver med sine særegenheter, egnet til spesifikke oppgaver.

en: Installing Packages
nb-NO: Installasjon av pakker

en: <primary>installation</primary><secondary>package installation</secondary>
nb-NO: <primary>installasjon</primary><secondary>pakkeinstallasjon</secondary>

en: <command>dpkg</command> is, above all, the tool for installing an already available Debian package (because it does not download anything). To do this, we use its <literal>-i</literal> or <literal>--install</literal> option.
nb-NO: <command>dpkg</command> er fremfor alt verktøyet for å installere en allerede tilgjengelig Debian-pakke (fordi den ikke laster ned noe). For å gjøre det velger vi <literal>-i</literal> eller <literal>--install</literal> alternativet.

en: Installation of a package with <command>dpkg</command>
nb-NO: Installasjon av en pakke med <command>dpkg</command>

en: We can see the different steps performed by <command>dpkg</command>; we know, thus, at what point any error may have occurred. The installation can also be effected in two stages: first unpacking, then configuration. <command>apt</command> takes advantage of this, limiting the number of calls to <command>dpkg</command> (since each call is costly, due to loading of the database in memory, especially the list of already installed files).
nb-NO: Vi kan se de ulike trinnene utført av <command>dpkg</command>, dermed også ved hvilket punkt en eventuell feil har oppstått. Hver pakke installeres i to trinn; først utpakking, deretter oppsett. <command>apt</command> utnytter dette til å begrense antall kall til <command>dpkg</command> (siden hvert kall er kostbart på grunn av innlasting av databasen i minnet, spesielt listen over allerede installerte filer).

en: Separate unpacking and configuration
nb-NO: Separat utpakking og oppsett

en: <primary>package</primary><secondary>unpacking</secondary>
nb-NO: <primary>pakke</primary><secondary>utpakking</secondary>

en: Sometimes <command>dpkg</command> will fail to install a package and return an error; if the user orders it to ignore this, it will only issue a warning; it is for this reason that we have the different <literal>--force-*</literal> options. The <command>dpkg --force-help</command> command, or documentation of this command, will give a complete list of these options. The most frequent error, which you are bound to encounter sooner or later, is a file collision. When a package contains a file that is already installed by another package, <command>dpkg</command> will refuse to install it. The following messages will then appear:
nb-NO: Noen ganger vil <command>dpkg</command> mislykkes med å installere en pakke, og melde om feil: Hvis brukeren beordrer den til å overse dette, vil den bare sende en advarsel. Det er derfor vi har de ulike <literal>--force-*</literal> valgmulighetene. <command>dpkg --force-help</command>-kommandoen, eller dokumentasjon for denne kommandoen, vil gi en fullstendig liste over disse alternativene. Den hyppigste feilen, som du er nødt til å treffe på før eller senere, er en filkollisjon. Når en pakke inneholder en fil som allerede er installert av en annen pakke, vil <command>dpkg</command>-kommandoen avslå å installere den. Da vil det følgende budskapet vises:

en: In this case, if you think that replacing this file is not a significant risk to the stability of your system (which is usually the case), you can use the option <literal>--force-overwrite</literal>, which tells <command>dpkg</command> to ignore this error and overwrite the file.
nb-NO: I dette tilfellet, hvis du tror at det ikke er en betydelig risiko for stabiliteten i systemet å erstatte denne filen (hvilket vanligvis er tilfelle), kan du bruke alternativet <literal>--force-overwrite</literal>, som ber <command>dpkg</command> om å ignorere denne feilen og overskrive filen.

en: <emphasis>CAUTION</emphasis> Effective use of <literal>--force-*</literal>
nb-NO: <emphasis>VÆR VARSOM</emphasis> Effektiv bruk av <literal>--force-*</literal>

en: <primary>broken dependency</primary>
nb-NO: <primary>brutt avhengighet</primary>

en: If you are not careful, the use of an option <literal>--force-*</literal> can lead to a system where the APT family of commands will refuse to function. In effect, some of these options allow installation of a package when a dependency is not met, or when there is a conflict. The result is an inconsistent system from the point of view of dependencies, and the APT commands will refuse to execute any action except those that will bring the system back to a consistent state (this often consists of installing the missing dependency or removing a problematic package). This often results in a message like this one, obtained after installing a new version of <emphasis role="pkg">rdesktop</emphasis> while ignoring its dependency on a newer version of the <emphasis role="pkg">libc6</emphasis>:
nb-NO: Hvis du ikke er forsiktig, kan bruken av valget <literal>--force-*</literal> føre til et system hvor APT-kommandofamilien vil nekte å fungere. Faktisk vil noen av disse alternativene tillate installasjon av en pakke selv om en avhengighet ikke er oppfylt, eller når det er en konflikt. Resultatet er et ikke-konsistent system sett fra et avhengighetssynspunkt, og APT-kommandoer vil nekte å utføre handlinger, med unntak av de som vil bringe systemet tilbake til en konsistent tilstand (dette består ofte av å installere den manglende avhengighet, eller fjerne en problematisk pakke). Dette resulterer ofte i en melding lik dette, som kom etter installasjon av en ny versjon av <emphasis role="pkg">rdesktop</emphasis> mens man så bort fra dennes avhengigheten til en nyere versjon av <emphasis role="pkg">libc6</emphasis>:

en: A courageous administrator who is certain of the correctness of their analysis may choose to ignore a dependency or conflict and use the corresponding <literal>--force-*</literal> option. In this case, if they want to be able to continue to use <command>apt</command> or <command>aptitude</command>, they must edit <filename>/var/lib/dpkg/status</filename> to delete/modify the dependency, or conflict, that they chose to override.
nb-NO: En modig administrator, som er sikker på at sine analyser er riktig, kan velge å ignorere en avhengighet eller konflikt, og bruker det aktuelle <literal>--force-*</literal>-valget. I dette tilfellet, hvis de ønsker å kunne forutsette å bruke <command>apt</command>, eller <command>aptitude</command>, må de redigere <filename>/var/lib/dpkg/status</filename> for å slette/endre avhengigheten, eller konflikten, som de valgte å overstyre.

en: This manipulation is an ugly hack, and should never be used, except in the most extreme case of necessity. Quite frequently, a more fitting solution is to recompile the package that is causing the problem (see <xref linkend="sect.rebuilding-package" />) or use a new version (potentially corrected) from a repository such as the <literal>stable-backports</literal> one (see <xref linkend="sect.apt-sources.list.stable.backports" />).
nb-NO: Denne manipulasjon er en stygg rettelse, og bør aldri brukes, unntatt når det absolutt kreves. Ganske ofte er en mer passende løsning å bygge pakken som forårsaker problemet på nytt (se <xref linkend="sect.rebuilding-package" />), eller bruke en ny versjon (som muligens er rettet) fra et kodelager som <literal>stable-backports</literal> (se <xref linkend="sect.apt-sources.list.stable.backports" />)..

en: Invoking <command>dpkg</command> with the <literal>-r</literal> or <literal>--remove</literal> option, followed by the name of a package, removes that package. This removal is, however, not complete: all of the configuration files, maintainer scripts, log files (system logs) and other user data handled by the package remain. That way disabling the program is easily done by uninstalling it, and it is still possible to quickly reinstall it with the same configuration. To completely remove everything associated with a package, use the <literal>-P</literal> or <literal>--purge</literal> option, followed by the package name.
nb-NO: Å aktivere <command>dpkg</command> med <literal>-r</literal> eller <literal>--remove</literal>-valget, etterfulgt av navnet på en pakke, fjerner denne pakken. Denne fjerningen er imidlertid ikke komplett: Alle oppsettsfiler, vedlikeholderskript, loggfiler (systemlogger) og andre brukerdata som håndteres av pakken blir igjen. Dette gjør det enkelt å koble ut programmet ved å avinstallere det, og det kan raskt tilbakeføres med samme oppsett ved å installere det på nytt. For å fjerne alt som er tilknyttet en pakke kan du bruke <literal>-P</literal> eller <literal>-- purge</literal>-valget, fulgt av pakkenavnet.

en: Removal and purge of the <emphasis role="pkg">debian-cd</emphasis> package
nb-NO: Fjerning og fullstendig fjerning av <emphasis role="pkg">debian-cd</emphasis>-pakken

en: Querying <command>dpkg</command>'s Database and Inspecting <filename>.deb</filename> Files
nb-NO: Spørre databasen til <command>dpkg</command>, og inspisere <filename>.deb</filename>-filer

en: <primary>package</primary><secondary>status</secondary>
nb-NO: <primary>pakke</primary><secondary>status</secondary>

en: <primary>package</primary><secondary>file list</secondary>
nb-NO: <primary>pakke</primary><secondary>filliste</secondary>

en: <primary>package</primary><secondary>content inspection</secondary>
nb-NO: <primary>pakke</primary><secondary>innholdssjekk</secondary>

en: <emphasis>BACK TO BASICS</emphasis> Option syntax
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Argument-syntaks

en: Most options are available in a “long” version (one or more relevant words, preceded by a double dash) and a “short” version (a single letter, often the initial of one word from the long version, and preceded by a single dash). This convention is so common that it is a POSIX standard.
nb-NO: De fleste argumenter er tilgjengelige i en «lang» versjon (en eller flere relevante ord, innledet med en dobbel bindestrek), og en «kort» versjon (en enkelt bokstav, ofte den første av ett ord fra den lange versjonen, og innledet med en enkelt bindestrek). Denne konvensjonen er så vanlig at den er en POSIX-standard.

en: Before concluding this section, we will study <command>dpkg</command> options that query the internal database in order to obtain information. Giving first the long options and then corresponding short options (that will evidently take the same possible arguments) we cite
nb-NO: Før konklusjonen i denne delen vil man ta for seg <command>dpkg</command>-alternativene man kan kjøre som spørringer i den interne databasen for å hente info. Først kommer de lange formene, og så tilsvarende i kortform (som også tar de samme mulige argumentene)

en: <literal>--listfiles <replaceable>package</replaceable></literal> (or <literal>-L</literal>), which lists the files installed by this package;
nb-NO: <literal>--listfiles <replaceable>pakke</replaceable></literal> (eller <literal>-L</literal>), som lister opp filer installert av denne pakken;

en: <literal>--search <replaceable>file</replaceable></literal> (or <literal>-S</literal>), which finds the package(s) containing the file;
nb-NO: <literal>--search <replaceable>fil</replaceable></literal> (eller <literal>-S</literal>), som finner pakk(ene) som inneholder filen;

en: <literal>--status <replaceable>package</replaceable></literal> (or <literal>-s</literal>), which displays the headers of an installed package;
nb-NO: <literal>--status <replaceable>pakke</replaceable></literal> (eller <literal>-s</literal>), som viser hodene tilhørende en installert pakke;

en: <literal>--list</literal> (or <literal>-l</literal>), which displays the list of packages known to the system and their installation status;
nb-NO: <literal>--list</literal> (eller <literal>-l</literal>), som viser listen over pakker kjent for systemet og deres installasjonsstatus;

en: <literal>--info<replaceable> file.deb </replaceable></literal> (or <literal>-I</literal>), which displays the headers of this Debian package.
nb-NO: <literal>--info<replaceable> file.deb </replaceable></literal> (eller <literal>-I</literal>), som viser hodene for denne Debian-pakken.

en: <emphasis>CAUTION</emphasis> <command>dpkg --search</command> and merged <filename>/usr</filename>
nb-NO: <emphasis>VÆR VARSOM</emphasis> <command>dpkg --search</command> og sammenvevd <filename>/usr</filename>

en: <primary>merged <filename>/usr</filename></primary>
nb-NO: <primary>sammenvevd<filename>/usr</filename></primary>

en: For <ulink url="https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/">various reasons</ulink>, Debian now installs by default a few top-level directories as symlinks to their counterparts below <filename>/usr</filename>. For instance, <filename>/bin</filename>, <filename>/sbin</filename> and <filename>/lib</filename> are now symlinks to, respectively, <filename>/usr/bin</filename>, <filename>/usr/sbin</filename> and <filename>/usr/lib</filename>.
nb-NO: Av <ulink url="https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/">ulike årsaker</ulink>, installerer Debian nå, som standard, noen få mapper på toppnivå som symlenker til sine motparter under <filename>/usr</filename>. <filename>/bin</filename>, <filename>/sbin</filename> og <filename>/lib</filename> er nå symlenker til henholdsvis <filename>/usr/bin</filename>, <filename>/usr/sbin</filename> og <filename>/usr/lib</filename>.

en: While this does provide desirable benefits, it can also be a source of confusion. For example, when you query <command>dpkg</command> which package is owning a given file, it will only be able to answer when you ask for its original path:
nb-NO: Mens dette gir ønskelige fordeler, kan det også være en kilde til forvirring. Når du for eksempel spør <command>dpkg</command> hvilken pakke som eier en gitt fil, vil den bare kunne svare når du ber om den opprinnelige banen:

en: This issue is currently tracked as bug #858331. There is also an ongoing discussion if the approach used so far is counterproductive. <ulink type="block" url="https://bugs.debian.org/858331" />
nb-NO: Problemet har feilrapport #858331. Diskusjonen om hvorvidt nåværende angrepsvinkel er kontraproduktiv ruller også. <ulink type="block" url="https://bugs.debian.org/858331" />

en: Various queries with <command>dpkg</command>
nb-NO: Forskjellige søk med <command>dpkg</command>

en: <emphasis>GOING FURTHER</emphasis> Comparison of versions
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Sammenligning av versjoner

en: <primary>version, comparison</primary>
nb-NO: <primary>versjon, sammenligning</primary>

en: <primary>comparison of versions</primary>
nb-NO: <primary>sammenligning av versjoner</primary>

en: <primary>package</primary><secondary>version, comparison</secondary>
nb-NO: <primary>pakke</primary><secondary>versjon, sammenligning</secondary>

en: Since <command>dpkg</command> is the program for handling Debian packages, it also provides the reference implementation of the logic of comparing version numbers. This is why it has a <literal>--compare-versions</literal> option, usable by external programs (especially configuration scripts executed by <command>dpkg</command> itself). This option requires three parameters: a version number, a comparison operator, and a second version number. The different possible operators are <literal>lt</literal> (strictly less than), <literal>le</literal> (less than or equal to), <literal>eq</literal> (equal), <literal>ne</literal> (not equal), <literal>ge</literal> (greater than or equal to), and <literal>gt</literal> (strictly greater than). If the comparison is correct, <command>dpkg</command> returns 0 (success); if not, it gives a non-zero return value (indicating failure).
nb-NO: Ettersom <command>dpkg</command> er programmet som behandler Debian-pakker, gir det også referanseimplementeringen for logikken som skal til for å sammenligne versjonsnumre. Dette er grunnen til at det har en <literal>--compare-versions</literal>-valgmulighet, som kan brukes av eksterne programmer (spesielt oppsettsskript som kjøres med <command>dpkg</command> selv). Denne valgmuligheten krever tre parametre: Et versjonsnummer, en sammenligningsoperator, og et andre versjonsnummer. De forskjellige mulige operatorene er <literal>lt</literal> (absolutt mindre enn), <literal>le</literal> (mindre enn eller lik), <literal>eq</literal> (lik), <literal>ne</literal> (ikke lik), <literal>ge</literal> (større enn eller lik), og <literal>gt</literal> (absolutt større enn). Hvis sammenligningen er riktig, returnerer <command>dpkg</command> 0 (suksess); hvis ikke, gir den en ikke-zero verdi tilbake (som indikerer feil).

en: Note the unexpected failure of the last comparison: for <command>dpkg</command>, <literal>pre</literal>, usually denoting a pre-release, has no particular meaning, and this program compares the alphabetic characters in the same way as the numbers (a &lt; b &lt; c ...), in alphabetical order. This is why it considers “<literal>0pre3</literal>” to be greater than “<literal>0</literal>”. When we want a package's version number to indicate that it is a pre-release, we use the tilde character, “<literal>~</literal>”:
nb-NO: Legg merke til den uventede feilen i den siste sammenligningen: For <command>dpkg</command> betegner <literal>pre</literal> vanligvis en testutgave, og har forøvrig ingen spesiell betydning, og dette programmet sammenligner bokstaver på samme måte som tallene (en &lt; b &lt; c ...), i alfabetisk rekkefølge. Dette er grunnen til at det vurderer «<literal>0pre3</literal>» til å være større enn «<literal>0</literal>». Når vi ønsker et pakkeversjonsnummer som viser at det er en testutgave, så bruker vi tilde-tegnet, «<literal>~</literal>»:

en: <command>dpkg</command>'s Log File
nb-NO: Loggfilen til <command>dpkg</command>

en: <command>dpkg</command> keeps a log of all of its actions in <filename>/var/log/dpkg.log</filename>. This log is extremely verbose, since it details every one of the stages through which packages handled by <command>dpkg</command> go. In addition to offering a way to track dpkg's behavior, it helps, above all, to keep a history of the development of the system: one can find the exact moment when each package has been installed or updated, and this information can be extremely useful in understanding a recent change in behavior. Additionally, all versions being recorded, it is easy to cross-check the information with the <filename>changelog.Debian.gz</filename> for packages in question, or even with online bug reports.
nb-NO: <command>dpkg</command> tar vare på en logg med alle handlinger i <filename>/var/log/dpkg.log</filename>. Denne loggen er ekstremt ordrik, med detaljer for hver og en av de stadier som pakker, håndtert av <command>dpkg</command>, gjennomgår. I tillegg til å gi en måte å spore dpkgs oppførsel på, hjelper den fremfor alt til med å beholde en historie om utviklingen av systemet: Man kan finne det nøyaktige øyeblikket når hver pakke er installert eller oppdatert, og denne informasjonen kan være svært nyttig i å forstå en nylig endring i oppførselen. I tillegg er alle versjoner tatt vare på, så det er lett å kryssjekke informasjonen med <filename>changelog.Debian.gz</filename> for de pakker det gjelder, eller også med online bug-rapporter.

en: Multi-Arch Support
nb-NO: Støtte for multiarkitektur

en: <primary>architecture</primary><secondary>multi-arch support</secondary>
nb-NO: <primary>arkitektur</primary><secondary>multi-arch støtte</secondary>

en: All Debian packages have an <literal>Architecture</literal> field in their control information. This field can contain either “<literal>all</literal>” (for packages that are architecture independent) or the name of the architecture that it targets (like “amd64”, “armhf”, …). In the latter case, by default, <command>dpkg</command> will only accept to install the package if its architecture matches the host's architecture as returned by <command>dpkg --print-architecture</command>.
nb-NO: Alle Debian-pakker har et <literal>Architecture</literal>-felt i kontrollinformasjonen. Dette feltet kan inneholde enten «<literal>all</literal>» (for pakker som er arkitekturuavhengig), eller navnet på den arkitekturen som den er rettet mot (som «amd64», «armhf», ...). I det sistnevnte tilfellet vil, som utgangspunkt, <command>dpkg</command> bare akseptere å installere pakken hvis arkitekturen svarer til vertsmaskinens arkitektur som meldt tilbake fra <command>dpkg --print-architecture</command>.

en: This restriction ensures that users do not end up with binaries compiled for an incorrect architecture. Everything would be perfect except that (some) computers can run binaries for multiple architectures, either natively (an “amd64“ system can run “i386” binaries) or through emulators.
nb-NO: Denne begrensningen sikrer at brukerne ikke ender opp med binærfiler kompilert for feil arkitektur. Alt ville være perfekt, bortsett fra at (noen) datamaskiner kan kjøre binærfiler for flere arkitekturer, enten innebygd (et «amd64»-system kan kjøre "i386" binærfiler), eller ved hjelp av emulatorer.

en: Enabling Multi-Arch
nb-NO: Aktivere multi-arkitektur

en: <command>dpkg</command>'s multi-arch support allows users to define “foreign architectures” that can be installed on the current system. This is simply done with <command>dpkg --add-architecture</command> like in the example below. There is a corresponding <command>dpkg --remove-architecture</command> to drop support of a foreign architecture, but it can only be used when no packages of this architecture remain.
nb-NO: <command>dpkg</command>s multi-arkitekturstøtte tillater brukere å definere «fremmede arkitekturer» som kan installeres på det gjeldende systemet. Dette gjøres rett og slett med <command>dpkg --add-architecture</command> som i eksemplet nedenfor. Det er en tilsvarende <command>dpkg --remove-architecture</command> til å droppe støtte til en fremmed arkitektur, men den kan bare brukes når ingen pakker med denne arkitekturen er igjen.

en: <emphasis>NOTE</emphasis> APT's multi-arch support
nb-NO: <emphasis>MERK</emphasis> APTs multi-arkitekturstøtte

en: APT will automatically detect when dpkg has been configured to support foreign architectures and will start downloading the corresponding <filename>Packages</filename> files during its update process.
nb-NO: APT vil automatisk oppdage når dpkg er satt opp til å støtte fremmede arkitekturer, og vil gå igang med å laste ned aktuelle <filename>Packages</filename>-filer som ledd i oppdateringsprosessen.

en: Foreign packages can then be installed with <command>apt install <replaceable>package</replaceable>:<replaceable>architecture</replaceable></command>.
nb-NO: Fremmede pakker kan installeres med <command>apt install <replaceable>pakke</replaceable>:<replaceable>arkitektur</replaceable></command>.

en: <emphasis>IN PRACTICE</emphasis> Using proprietary i386 binaries on amd64
nb-NO: <emphasis>I PRAKSIS</emphasis> Ved hjelp av proprietære i386 binærfiler på amd64

en: There are multiple use cases for multi-arch, but the most popular ones are the possibility to execute (sometimes proprietary) 32 bit binaries (i386) on 64 bit systems (amd64), and the possibility to cross-compile software for a platform or an architecture different from the host one.
nb-NO: Det er flere bruksområder for multi-arkitektur, men de mest populære er muligheten til å kjøre (noen ganger proprietære) 32 bit binærfiler (i386) på 64 bit systemer (amd64), og muligheten til å krysskompilere programvare for en plattform eller en arkitektur som er forskjellig fra vertens.

en: Multi-Arch Related Changes
nb-NO: Multi-arkitekturrelaterte endringer

en: To make multi-arch actually useful and usable, libraries had to be repackaged and moved to an architecture-specific directory so that multiple copies (targeting different architectures) can be installed alongside. Such updated packages contain the “<literal>Multi-Arch: same</literal>” header field to tell the packaging system that the various architectures of the package can be safely co-installed (and that those packages can only satisfy dependencies of packages of the same architecture). The most important libraries have been converted since the introduction of multi-arch in Debian 7 <emphasis role="distribution">Wheezy</emphasis>, but there are many libraries that will likely never be converted unless someone specifically requests it (through a bug report for example).
nb-NO: For å gjøre multi-arch faktisk nyttig og brukbar, måtte biblioteker pakkes om og flyttes til en arkitektur-spesifikk katalog slik at flere kopier (rettet mot ulike arkitekturer) kan installeres sammen. Slike oppdaterte pakker inneholder hodefeltet «<literal>Multi-Arch: same</literal>» for å fortelle pakkesystemet at de ulike arkitekturene i pakken trygt kan installeres samtidig (og at disse pakkene bare kan tilfredsstille avhengigheter for pakker av samme arkitektur). De viktigste bibliotekene har blitt konvertert etter innføringen av multi-arch i Debian 7 <emphasis role="distribution">Wheezy</emphasis>, men det er mange biblioteker som sannsynligvis aldri vil bli konvertert med mindre noen spesifikt ber om det (for eksempel via en feilrapport).

en: It is worth noting that <literal>Multi-Arch: same</literal> packages must have their names qualified with their architecture to be unambiguously identifiable. They also have the possibility to share files with other instances of the same package; <command>dpkg</command> ensures that all packages have bit-for-bit identical files when they are shared. Last but not least, all instances of a package must have the same version. They must thus be upgraded together.
nb-NO: Det er verd å merke seg at <literal>Multi-Arch: same</literal>-pakker må ha navnet sitt kvalifisert med arkitektur for å være entydig identifiserbar. De har også muligheten til å dele filer med andre forekomster med den samme pakken; <command>dpkg</command> sikrer at alle pakkene har bit-for-bit-identiske filer når de deles. Sist men ikke minst, må alle forekomster av en pakke ha den samme versjonen. De må dermed oppgraderes sammen.

en: Multi-Arch support also brings some interesting challenges in the way dependencies are handled. Satisfying a dependency requires either a package marked “<literal>Multi-Arch: foreign</literal>” or a package whose architecture matches the one of the package declaring the dependency (in this dependency resolution process, architecture-independent packages are assumed to be of the same architecture than the host). A dependency can also be weakened to allow any architecture to fulfill it, with the <literal><replaceable>package</replaceable>:any</literal> syntax, but foreign packages can only satisfy such a dependency if they are marked “<literal>Multi-Arch: allowed</literal>”.
nb-NO: Multi-arkitekturstøtte gir også noen interessante utfordringer i måten avhengigheter håndteres. Å tilfredsstille en avhengighet krever enten en pakke merket «<literal>Multi-Arch: foreign</literal>», eller en pakke hvis arkitektur samsvarer med den ene av pakken som inneholder avhengigheten (i denne prosessen med avhengighetsavklaring er arkitekturuavhengige pakker antatt å ha den samme arkitektur som verten). En avhengighet kan også bli svekket ved å tillate ulike arkitekturer å imøtekomme den, med <literal><replaceable>pakke</replaceable>:any</literal>-syntaks, men fremmede pakker kan bare tilfredsstille en slik avhengighet hvis de er merket «<literal>Multi-Arch: allowed</literal>».

en: Coexistence with Other Packaging Systems
nb-NO: Sameksistens med andre pakkesystemer

en: Debian packages are not the only software packages used in the free software world. The main competitor is the RPM format of the Red Hat Linux distribution and its many derivatives. Red Hat is a very popular, commercial distribution. It is thus common for software provided by third parties to be offered as RPM packages rather than Debian.
nb-NO: Debian-pakker er ikke de eneste programvarepakkene som brukes i fri programvareverden. Den viktigste konkurrent er RPM-formatet til Red Hat Linux-distribusjon og dens mange avledede distribusjoner. Red Hat er en veldig populær, kommersiell distribusjon. Det er derfor vanlig at programvare levert av tredjeparter blir tilbudt som RPM-pakker i stedet for Debian.

en: In this case, you should know that the program <command>rpm</command>, which handles RPM packages, is available as a Debian package, so it is possible to use this package format on Debian. Care should be taken, however, to limit these manipulations to extract the information from a package or to verify its integrity. It is, in truth, unreasonable to use <command>rpm</command> to install an RPM on a Debian system; RPM uses its own database, separate from those of native software (such as <command>dpkg</command>). This is why it is not possible to ensure a stable coexistence of two packaging systems.
nb-NO: I dette tilfellet skal du vite at programmet <command>rpm</command>, som behandler RPM-pakker, er tilgjengelig som en Debian-pakke, så det er mulig å bruke dette pakkeformatet på Debian. Imidlertid bør forsiktighet utvises for å begrense disse håndteringene med å trekke ut informasjon fra en pakke, eller for å få bekreftet integriteten. Det er i sannhet urimelig å bruke <command>rpm</command> for å installere en RPM i et Debian-system; RPM bruker sin egen database, atskilt fra de til systemprogramvare (som <command>dpkg</command>). Dette er grunnen til at det ikke er mulig å sikre en stabil sameksistens mellom to pakkesystemer.

en: On the other hand, the <emphasis role="pkg">alien</emphasis> utility can convert RPM packages into Debian packages, and vice versa.
nb-NO: På den annen side, <emphasis role="pkg">alien</emphasis>-verktøyet kan konvertere RPM-pakker til Debian-pakker og vice versa.

en: <emphasis>COMMUNITY</emphasis> Encouraging the adoption of <filename>.deb</filename>
nb-NO: <emphasis>FELLESSKAP</emphasis> Oppmuntre til å ta i bruk <filename>.deb</filename>

en: You will find that this process is extremely simple. You must know, however, that the package generated does not have any dependency information, since the dependencies in the two packaging formats don't have systematic correspondence. The administrator must thus manually ensure that the converted package will function correctly, and this is why Debian packages thus generated should be avoided as much as possible. Fortunately, Debian has the largest collection of software packages of all distributions, and it is likely that whatever you seek is already in there.
nb-NO: Du vil finne at denne prosessen er svært enkel. Du må imidlertid vite at pakken som genereres ikke har noen informasjon om avhengighet, siden avhengigheter i de to pakkeformater ikke har systematisk samsvar. Administratoren må derfor manuelt sørge for at den konverterte pakken vil fungere på riktig måte, og dette er grunnen til Debian-pakker generert slik bør unngås så mye som mulig. Heldigvis har Debian den største samlingen av programvarepakker av alle distribusjoner, og det er sannsynlig at uansett hva du leter etter, er det allerede tilgjengelig.

en: Looking at the man page for the <command>alien</command> command, you will also note that this program handles other packaging formats, especially the one used by the Slackware distribution (it is made of a simple <filename>tar.gz</filename> archive).
nb-NO: Ser du på manualsiden for <command>alien</command>-kommandoen, vil du legge merke til at dette programmet håndterer andre pakkeformater, spesielt de som brukes av Slackware-distribusjonen (som består av et enkelt <filename>tar.gz</filename>-arkiv).

en: The stability of the software deployed using the <command>dpkg</command> tool contributes to Debian's fame. The APT suite of tools, described in the following chapter, preserves this advantage, while relieving the administrator from managing the status of packages, a necessary but difficult task.
nb-NO: Stabiliteten til programvare som er rullet ut med <command>dpkg</command>-verktøyet bidrar til Debians berømmelse. APT-verktøypakken, beskrevet i neste kapittel, tar vare på denne fordelen, samt sparer administratoren fra å håndtere pakkenes status – en nødvendig, men vanskelig oppgave.
