15.2. Å bygge din første pakke

15.2.1. Meta-pakker eller falske pakker

Falske pakker og meta-pakker er like ved at de er tomme skall som bare eksisterer for effektene meta-dataene deres har på pakkehåndteringsstabelen.

Formålet med en falsk pakke er å lure dpkg og apt til å tro at noen pakker er installert, selv om de bare er et tomt skall. Dette tillater å tilfredsstille avhengigheter i en pakke når den tilsvarende programvaren ble installert utenfor rammen av pakkesystemet. En slik metode fungerer, men bør likevel unngås når det er mulig, ettersom det ikke er noen garanti for at den manuelt installerte programvaren oppfører seg akkurat som den tilsvarende pakken ville ha gjort, og andre pakker som er avhengig av den, ikke vil fungere ordentlig.

På den annen side, en meta-pakke består oftest som en samling av avhengigheter, slik at montering av meta-pakken faktisk vil føre inn et sett av andre pakker i et enkelt trinn.

Begge disse pakkesalgene kan lages av kommandoene equivs-control og equivs-build (i equivs-pakken). Kommandoene equivs-control filen oppretter en Debian-pakke topptekstfil som skal redigeres for å inneholde navnet på den forventede pakken, dens versjonsnummer, navnet på vedlikeholderen, avhengighetene, og beskrivelsen. Andre felt uten en standardverdi er valgfrie, og kan slettes. Feltene Copyright, Changelog, Readme og Extra-Files er ikke standard felt i Debian-pakker; de bare gir mening innenfor rammen av equivs-build, og de vil ikke bli beholdt i overskriftene til den genererte pakken.

Eksempel 15.2. Topptekstfil for den falske pakken libxml-libxml-perl

Section: perl
Priority: optional
Standards-Version: 3.9.6

Package: libxml-libxml-perl
Version: 2.0116-1
Maintainer: Raphael Hertzog <hertzog@debian.org>
Depends: libxml2 (>= 2.7.4)
Architecture: all
Description: Fake package - module manually installed in site_perl
 This is a fake package to let the packaging system
 believe that this Debian package is installed. 
 .
 In fact, the package is not installed since a newer version
 of the module has been manually compiled & installed in the
 site_perl directory.

Det neste skrittet er å generere Debian-pakken med kommandoen equivs-build filen. Og plutselig er pakken opprettet i den gjeldende katalogen, og kan håndteres som enhver annen Debian-pakke ville blitt.

15.2.2. Et enkelt filarkiv

For å lette utplasseringen av et sett med dokumentasjon på et stort antall maskiner, trenger Falcot Corp-administratorene å lage en Debian-pakke. Administratoren med ansvaret for denne oppgaven leser først «Guide for nye Debian vedlikeholder» («New Maintainer's Guide»), og begynner så å jobbe med sin første pakke.

→ https://www.debian.org/doc/manuals/maint-guide/

Det første skrittet er å lage en falcot-data-1.0-mappe som skal inneholde mål-kildepakken. Pakken vil logisk nok få navnet falcot-data, og bære versjonsnummeret 1.0. Administratoren plasserer så dokumentasjonsfilene i en data-undermappe. Så påkaller de dh_make-kommandoen (fra dh-make-pakken) for å legge til filene som kreves for pakke-genereringsprosessen - som alle blir lagret i en debian-undermappe:

$ cd falcot-data-1.0
$ dh_make --native

Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
 [s/i/m/l/k/n] i

Maintainer name : Raphael Hertzog
Email-Address   : hertzog@debian.org
Date            : Fri, 04 Sep 2015 12:09:39 -0400
Package Name    : falcot-data
Version         : 1.0
License         : gpl3
Type of Package : Independent
Hit <enter> to confirm:
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the falcot-data Makefiles install into $DESTDIR and not in / .
$

Den valgte pakketypen (enkelt binære (indep binary)) indikerer at denne kildepakken vil generere en enkelt binærpakke som kan deles på tvers av alle arkitekturer (Architecture: all). enkelt binære virker som en motpart, og fører til en enkelt binærpakke som er avhengig av målarkitekturen (Architecture: any). I dette tilfellet er valget mer relevant, siden pakken bare inneholder dokumentasjon, og ingen binære programmer, slik at den kan brukes på samme måten på datamaskiner av alle arkitekturer.

multippel binær-typen svarer til en kildekodepakke som leder til forskjellige binærpakker. Et spesielt tilfelle, bibliotek, er nyttig for delte biblioteker, siden de må følge strenge pakkeregler. På lignende måte skal kernel module, eller kernel patch begrenses til pakker som inneholder kjernemoduler.

TIPS Vedlikeholders navn og e-post

De fleste programmene involvert i pakkevedlikeholdet vil søke etter ditt navn og e-postadresse i DEBFULLNAME og DEBEMAIL, eller EMAIL-miljøvariabler. Ved å definere dem en gang for alle, vil du unngå å måtte sortere dem flere ganger. Hvis ditt vanlige skall er bash, er det bare å legge til følgende to linjer i din ~/.bashrc-file (du vil ganske sikkert erstatte verdiene med noen mer relevante!):

export EMAIL="hertzog@debian.org"
export DEBFULLNAME="Raphael Hertzog"

Kommandoen dh_make laget en debian-undermappe med mange filer. Noen kreves, spesielt rules, control, changelog og copyright. Filer med .ex-forlengelsen er eksempelfiler som kan brukes ved å modifisere dem (og fjerne forlengelsen) når det passer. Når de ikke er nødvendige, anbefales det å fjerne dem. compat bør beholdes, ettersom den er nødvendig for riktig funksjon av debhelper-programpakken (som alle begynner med dh_-forstavelsen), og som brukes på ulike stadier i pakkebyggingsprosessen.

copyright må inneholde informasjon om forfatterne av dokumentasjonen som er inkludert i pakken, og den tilhørende lisensen. I vårt tilfelle er intern dokumentasjon og bruken av den begrenset til til Falcot Corp-selskapet. Standardfilen changelog er vanligvis hensiktsmessig; den erstatter «Første utgivelse» med en mer detaljert forklaring, og endre distribusjonen fra unstable til internal er nok. control-filen ble også oppdatert: Section-feltet er forandret til misc, og Homepage, Vcs-Git og Vcs-Browser-feltene ble forandret. Depends-feltene ble komplettert med iceweasel | www-browser for å sikre tilgjengeligheten for en pålitelig nettleser som kan vise dokumentasjonen i pakken.

Eksempel 15.3. control-filen

Source: falcot-data
Section: misc
Priority: optional
Maintainer: Raphael Hertzog <hertzog@debian.org>
Build-Depends: debhelper (>= 9)
Standards-Version: 3.9.5

Package: "falcot-data
Architecture: all
Depends: iceweasel | www-browser, ${misc:Depends}
Description: Internal Falcot Corp Documentation
 This package provides several documents describing the internal
 structure at Falcot Corp.  This includes:
  - organization diagram
  - contacts for each department.
 .
 These documents MUST NOT leave the company.
 Their use is INTERNAL ONLY.

Eksempel 15.4. changelog-filen

falcot-data (1.0) internal; urgency=low

  * Initial Release.
  * Let's start with few documents:
    - internal company structure;
    - contacts for each department.

 -- Raphael Hertzog <hertzog@debian.org>  Fri, 04 Sep 2015 12:09:39 -0400

Eksempel 15.5. copyright-filen

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: falcot-data

Files: *
Copyright: 2004-2015 Falcot Corp
License: 
 All rights reserved.

DET GRUNNLEGGENDE Makefile-fil

Makefile-filen er et skript som brukes av make-programmet: Det beskriver regler for hvordan man skal bygge et sett med filer fra hverandre i et tre med avhengigheter (for eksempel kan et program bygges fra et sett med kildefiler). Makefile-filen beskriver disse reglene i det følgende formatet:

target: source1 source2 ...
        command1
        command2

Tolkningen av slik regel er som følger: Hvis en av source*-filene er nyere enn target-filen, trenger målet generering ved å bruke command1 og command2.

Merk at kommandolinjene må starte med et TAB-tegn; Merk også at når en kommandolinje starter med en skråstrek (-), avbryter ikke feil i kommandoen hele prosessen.

Filen rules inneholder vanligvis et sett med regler til å sette opp, bygge og installere programvaren i en egen underkatalog (oppkalt etter den genererte binære pakken). Innholdet i denne underkatalogen blir deretter arkivert i Debian-pakken som om det var roten i filsystemet. I vårt tilfelle vil filene bli installert i debian/falcot-data/usr/share/falcot-data/-undermappe, slik at å installere den genererte pakken, vil plassere filene under /usr/share/falcot-data/. Filen rules blir brukt som en Makefile, med noen få standard mål (medregnet clean og binary, respektivt brukt til å rydde opp i kildemappen og generere binærpakken).

Selv om denne filen er hjertet av prosessen, inneholder den i økende grad bare et minimum for å kjøre et standard sett med kommandoer gitt av debhelper-verktøyet. Slik er tilfellet for filer generert av dh_make. For å installere våre filer må vi ganske enkelt sette opp atferden til dh_install-kommandoen ved å lage den følgende debian/falcot-data.install-filen:

data/* usr/share/falcot-data/

På dette tidspunktet kan pakken opprettes. Vi vil imidlertid legge til et malingstrøk. Siden administratorene ønsker at dokumentasjonen blir lett tilgjengelig fra menyene i grafiske skrivebordsmiljøer, legger vi til en falcot-data.desktop-file og får den installert i /usr/share/applications ved å legge til en andre linje til debian/falcot-data.install.

Eksempel 15.6. Filen falcot-data.desktop

[Desktop Entry]
Name=Internal Falcot Corp Documentation
Comment=Starts a browser to read the documentation
Exec=x-www-browser /usr/share/falcot-data/index.html
Terminal=false
Type=Application
Categories=Documentation;

Den oppdaterte debian/falcot-data.install ser slik ut:

data/* usr/share/falcot-data/
falcot-data.desktop usr/share/applications/

Vår kildepakke er nå klar. Alt som gjenstår å gjøre er å generere den binære pakken med den samme metoden vi brukte tidligere for å bygge om pakker: vi kjører dpkg-buildpackage -us -uc-kommandoen fra falcot-data-1.0-mappen.