Deb-paketin tekeminen
Debianissa ja siihen pohjautuvissa jakeluissa (esim. Knoppixissa, MEPISissä, PCLinuxOSissa ja Ubuntussa) käytetään Dpkg-paketinhallintajärjestelmää. Dpkg:ssa paketit ovat .deb-tiedostoja, jotka sisältävät itse ohjelman lisäksi mm. tiedot paketin riippuvuuksista ja siitä, mihin ohjelma asennetaan. Deb-pakettien tekeminen ei ole mitenkään ylivoimainen tehtävä, kunhan perusasiat ovat hallussa.
Tässä oppaassa luodaan aluksi malliksi yksinkertainen paketti GNU Hello -ohjelmasta, joka on GNU-projektin esimerkkiohjelma. Ohjelman lähdekoodipaketin voi ladata GNU:n palvelimelta. Paketin luomisessa käytetään tässä apuna Debhelper-apuohjelmaa. Tämä ei ole yksinkertaisin tapa paketoida ohjelma, mutta ennen helpottaviin tekniikoihin tutustumista on hyvä käydä asiat yksityiskohtaisemmin läpi.
Kun perusteet on hallussa, tutustumme artikkelin loppupuolella mm. CDBS:ään, joka helpottaa huomattavasti monia paketointiin liittyviä rutiinitehtäviä.
Valmistelut
Aluksi on asennettava muutamia perustyökaluja, jotka löytyvät seuraavista paketeista
Kun tarvittavat paketit on asennettu, lataa Hello-ohjelman lähdekoodi ja pura se työhakemistoosi. Nyt sinulla pitäisi olla työhakemistossasi tiedosto hello-2.2.tar.gz ja hakemisto hello-2.2.
Valmistelu
Aluksi kannattaa kokeilla, että saat ohjelman käännettyä ja ajettua. Sinun pitäisi osata tehdä tämä, jos luet tätä opasta, mutta lyhykäisyydessään voit asentaa Hellon hakemistoon ~/hello seuraavasti:
./configure --prefix=/home/käyttäjä/hello make make install
Nyt hakemistosta ~/hello pitäisi löytyä alihakemistot bin ja share, joissa Hellon tiedostot ovat.
Putsaa nyt hakemisto, jossa käänsit Hellon komennolla
make distclean
Nyt jos ohjelma kääntyi oikein, voimme aloittaa itse paketin tekemisen.
Pohja
Siirry ohjelman hakemistoon (hello-2.2) ja aja komento
dh_make -e sinun@sähköpostiosoitteesi -f ../hello-2.2.tar.gz
Toinen parametri on siis paketin tekijän sähköpostiosoite ja neljäs alkuperäinen lähdekooditiedosto. Kysyy aluksi, minkätyyppistä pakettia olemme luomassa:
Type of package: single binary, multiple binary, library, kernel module or cdbs? [s/m/l/k/b]
Vastaa tähän s (single binary), sillä olemme luomassa yksinkertaista yhden ohjelman käsittävää pakettia. Tämän jälkeen vahvista tiedot entterillä, jonka jälkeen dh_make luo hakemistoon debian-alihakemiston, joka sisältää tiedostot, joiden perusteella varsinainen paketti luodaan. Se myös luo ylähakemistoon tiedoston paketti_versio.orig.tar.gz, tässä tapauksessa siis hello_2.2.orig.tar.gz joka sisältää alkuperäisen lähdekoodipaketin.
Huomaa, että dh_make kuuluu ajaa vain kerran! Tulevien muutosten jälkeen sitä ei tarvitse (eikä saa) ajaa.
Asennushakemisto
Paketin luova työkalu päättelee paketin tiedostot siten, että ohjelma asennetaan sen valvonnassa väliaikaiseen alihakemistoon. Yleensä tämä alihakemisto on debian/paketin_nimi, jonne paketti asennetaan aivan normaalisti: esimerkiksi Hellon binääri menisi hakemistoon debian/hello-2.2/usr/bin/hello.
Autoconfia käyttävien pakettien kanssa (pääasiassa ohjelmat, jotka asennetaan komennolla ./configure && make && make install) paketin luoma työkalu osaa hoitaa tämän automaattisesti, eikä sinun tarvitse tässä vaiheessa tehdä mitään. Kuten huomasit asentaessamme ohjelmaa oppaan alussa, annoimme configure-skriptille parametrin --prefix=/hakemisto/jonne/ohjelma/asennetaan. Paketoija antaa configurelle samalla tavalla sopivan parametrin, jolloin ohjelma asentuu oikeaan paikkaan.
Jos ohjelma ei käytä autoconfia, on asennushakemistosta huolehdittava itse. Tämä tulee eteen kun myöhemmin muokkaamme tiedostoa debian/rules.
Asetustiedostot
Dh_make loi debian-hakemiston, joka sisältää monia tiedostoja, joiden perusteella itse paketti luodaan. Tässä vaiheessa on käytävä ne läpi ja muokattava sopiviksi.
control
Tiedostossa debian/control kerrotaan perustiedot paketista ja sen riippuvuuksista. Meidän tapauksessamme dh_make loi seuraavanlaisen pohjan (rivinumerot lisätty):
1 Source: hello 2 Section: unknown 3 Priority: extra 4 Maintainer: Paketin Tekijä <foo@bar.com> 5 Build-Depends: debhelper (>= 5), autotools-dev 6 Standards-Version: 3.7.2 7 8 Package: hello 9 Architecture: any 10 Depends: ${shlibs:Depends}, ${misc:Depends} 11 Description: <insert up to 60 chars description> 12 <insert long description, indented with spaces>
Riveillä 1-6 on lähdekoodipaketin (engl. source) perustiedot:
- Rivillä 1 on lähdekoodipaketin nimi
- Rivillä 2 kerrotaan, mihin osioon paketti kuuluu. Debianissa paketit osioihin, joita ovat mm. main (vapaat ohjelmat), non-free (ohjelmat, jotka eivät ole vapaita) ja contrib (ohjelmat, jotka riippuvat vapaista ohjelmista). Nämä ohjelmat on yhä jaettu pienempiin osioihin, kuten devel (kehitystyökalut) ja mail (sähköpostiohjelmat). Hellolle sopiva osio voisi olla text. Osiot on listattu Debian policyssä.
- Kolmannella rivillä kerrotaan, kuinka tärkeää käyttäjälle on asentaa tämä paketti. Vaikka "Terve maailma!" -viestin tulostava ohjelma voi tuntua tärkeältä, ehkäpä se ei kuitenkaan ole yhtä tärkeä kuin vaikka ydin, joten jätetään sen tärkeysasteeksi extra.
- Neljännellä rivillä on paketin tekijän nimi ja sähköpostiosoite
- Rivillä 5 listataan pilkulla erotettuna paketit, jotka tarvitaan tämän paketin kääntämiseen. Jos ohjelmasta on oltava tietty versio, haluttu versio voidaan ilmoittaa sulkeissa (esimerkissä tarvitaan debhelper-paketin versio 5 tai uudempi). Käytännössä aina tarvittavia paketteja (esim. gcc ja make) ei tarvitse luetella, sillä ne otetaan mukaan automaattisesti. Kuitenkin kaikki muut kääntämisessä tarvittavat vähänkin harvinaisemmat paketit on lueteltava. Tässä vaiheessa voitaisiin myös samalla tavalla luetella paketit, jotka estävät kääntämisen (Build-Conflicts: paketti1, paketti2). Hello on sen verran helppo kääntää, ettei meidän tarvitse nyt lisätä tähän mitään ylimääräisiä paketteja.
- Rivillä 6 kerrotaan, minkä Debian Policy -standardin version mukainen paketti on. Tähän ei tarvitse koskea.
- Rivillä 8 on varsinaisen binääripaketin nimi. Yleensä se on sama kuin lähdekoodipaketin nimi.
- Rivillä 9 kerrotaan, millä arkkitehtuurilla paketti toimii. Jätetään tämä arvoon "any", jolloin paketin tekevä työkalu huolehtii arkkitehtuurista. Jos paketti toimii kaikilla arkkitehtuureilla (esim. se on ohjepaketti tai Perl-skripti), arkkitehtuuriksi laitetaan "all".
- Rivillä 10 listataan paketit, jotka ovat binääripaketin riippuvuuksia. Koska Hello ei tarvitse mitään erityisiä paketteja, jätetään tämä tyhjäksi. "${shllibs:Debends}" huolehtii siitä, että kriittisimmät paketit, kuten libc, ovat asennettuina.
- Lopuksi paketille annetaan vielä lyhyt (suositus noin 60 merkkiä) ja pitkä kuvaus. Pitkä kuvaus kirjoitetaan tiedoston loppuun siten, että jokaisen rivin alussa on välilyönti. Näin lopullinen control-tiedosto voisi näyttää tältä:
Source: hello Section: text Priority: extra Maintainer: Tekijä <foo@bar.com> Build-Depends: debhelper (>= 5), autotools-dev Standards-Version: 3.7.2 Package: hello Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: Hello world -ohjelma Klassinen Hello world -ohjelma, jonka avulla opettelemme deb-pakettien tekemistä.
Suositeltavat paketit, konfliktit ja muut suhteet toisiin paketteihin
Riippuvuuksien lisäksi paketti voi myös suositella jonkun toisen paketin asentamista, tai se voi myös kieltäytyä asentumasta samaan järjestelmään jonkin toisen paketin kanssa (konfliktit). Tällaiset paketit esitellään control-tiedostossa samaan tapaan kuin riippuvuudet.
Riippuvuuksien lisäksi apt tukee seuraavia suhteita pakettien välillä:
- Recommends: Suositeltavat paketit. Yleensä paketteja, joita käytetään käytännössä aina tämän paketin kanssa. Esim. aptitude asentaa nämä automaattisesti, apt vain suosittelee.
- Suggests: Muita tämän paketin kanssa hyviä paketteja. Monet apt:n edustaohjelmat (kuten aptitude) näyttävät tämän listan, apt ei.
- Pre-Depends: Vahvempi kuin Depends. Vaatii, että paketit on asennettu ja otettu käyttöön ennen kuin suostuu asentamaan tämän paketin. Käytetään erittäin harvoin.
- Conflicts: Paketit, joiden kanssa tätä pakettia ei voida asentaa.
- Provides: Mitkä virtuaaliset paketit tämä paketti toteuttaa.
- Replaces: Paketit, jotka tämä paketti korvaa.
Jos esimerkiksi pakettimme nyt vaatisi paketin foo version 2.3 tai uudemman, paketti bar olisi myös kiva sen kanssa, ja pakettimme ei toimisi yhdessä libfoo:n kanssa, voisimme lisätä seuraavat rivit:
Depends: ${shlibs:Depends}, ${misc:Depends}, foo (>=2.3) Recommends: bar Conflicts: libfoo
Vastaavasti on mahdollista asettaa myös lähdekoodipaketille Build-Conflicts ja muut vastaavat suhteet.
copyright
Paketin tekijänoikeuksista kerrotaan tiedostossa debian/copyright. Tämän tiedoston muoto on periaatteessa vapaa, mutta hyvän tiedoston saa muokkaamalla dh_maken luomaa. Tässä tiedostosta tulee käydä ilmi paketin luoja, alkuperäinen tekijä ja ohjelman tekijänoikeustiedot (esim. GPL-lisenssin alainen).
changelog
dh_make luo seuraavanlaisen pohjan debian/changelog-tiedostolle: (rivinumerot lisätty)
1 hello (2.2-1) unstable; urgency=low 2 3 * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> 3 4 -- Tekijän Nimi <sähköposti@osoite.com> Sat, 21 Apr 2007 23:59:27 +0300
Rivillä 1 on aluksi paketin nimi (hello) ja versionumero (2.2-1). Seuraavana on jakelun nimi, johon paketti kuuluu (Debianilla on stable, testing ja unstable -jakelut). Unstable on yleensä hyvä. Viimeisenä on tieto paketin kiireellisyydestä (urgency), yleensä "low" on sille oikea arvo.
Tämän jälkeen seuraavilla riveillä on itse muutosloki (engl. changelog). Rivin alussa on kaksi välilyöntiä ja tähti (*). Viimeisenä (rivillä 4) on tieto paketin tekijästä ja tekoajankohdasta (esimerkin mukaisessa muodossa). Tämän rivin alussa on yksi välilyönti.
rules
Tiedosto debian/rules on Makefilen tapainen tiedosto, jonka perusteella varsinainen paketti luodaan. Tämän tiedoston perusteella ohjelma käännetään ja asennetaan hakemistoon debian/paketin_nimi, tässä tapauksessa debian/hello. Tähän hakemistoon asentuvien tiedostojen perusteella luodaan varsinainen paketti.
Koska Hello käyttää autoconfia, osaa paketin luova työkalu tehdä tarvittavat asetukset itse, eikä meidän periaatteessa tarvitse edes koskea rules-tiedostoon. Katsotaan nyt kuitenkin sitä malliksi, sillä vähänkin monimutkaisempien pakettien kohdalla sitä on muokattava. Dh_maken luoma malli on seuraava: (rivinumerot lisätty)
1 #!/usr/bin/make -f 2 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction. 7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 9 # Uncomment this to turn on verbose mode. 10 #export DH_VERBOSE=1 11 12 13 # These are used for cross-compiling and for saving the configure script 14 # from having to guess our platform (since we know it already) 15 DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) 16 DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) 17 18 19 CFLAGS = -Wall -g 20 21 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) 22 CFLAGS += -O0 23 else 24 CFLAGS += -O2 25 endif 26 27 config.status: configure 28 dh_testdir 29 # Add here commands to configure the package. 30 ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \ 31 --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs" 32 33 34 build: build-stamp 35 36 build-stamp: config.status 37 dh_testdir 38 39 # Add here commands to compile the package. 40 $(MAKE) 41 #docbook-to-man debian/hello.sgml > hello.1 42 43 touch $@ 44 45 clean: 46 dh_testdir 47 dh_testroot 48 rm -f build-stamp 49 50 # Add here commands to clean up after the build process. 51 -$(MAKE) distclean 52 ifneq "$(wildcard /usr/share/misc/config.sub)" "" 53 cp -f /usr/share/misc/config.sub config.sub 54 endif 55 ifneq "$(wildcard /usr/share/misc/config.guess)" "" 56 cp -f /usr/share/misc/config.guess config.guess 57 endif 58 59 60 dh_clean 61 62 install: build 63 dh_testdir 64 dh_testroot 65 dh_clean -k 66 dh_installdirs 67 68 # Add here commands to install the package into debian/hello. 69 $(MAKE) DESTDIR=$(CURDIR)/debian/hello install 70 71 72 # Build architecture-independent files here. 73 binary-indep: build install 74 # We have nothing to do by default. 75 76 # Build architecture-dependent files here. 77 binary-arch: build install 78 dh_testdir 79 dh_testroot 80 dh_installchangelogs ChangeLog 81 dh_installdocs 82 dh_installexamples 83 # dh_install 84 # dh_installmenu 85 # dh_installdebconf 86 # dh_installlogrotate 87 # dh_installemacsen 88 # dh_installpam 89 # dh_installmime 90 # dh_python 91 # dh_installinit 92 # dh_installcron 93 # dh_installinfo 94 dh_installman 95 dh_link 96 dh_strip 97 dh_compress 98 dh_fixperms 99 # dh_perl 100 # dh_makeshlibs 101 dh_installdeb 102 dh_shlibdeps 103 dh_gencontrol 104 dh_md5sums 105 dh_builddeb 106 107 binary: binary-indep binary-arch 108 .PHONY: build clean binary-indep binary-arch binary install
Tiedoston alussa annetaan käännösoptiot, esimerkiksi C-kääntäjän käännösparametrit laitetaan muuttujaan CFLAGS. Tämä tehdään riveillä 19-25.
Riveillä 27-31 ajetaan paketin configure-skripti. Koska Hello käyttää autoconfia ja siten configure-skriptiä, voimme välittää tässä vaiheessa tarvittavat parametrit. Saatat ihmetellä, miksi tässä annetaan parametrit --prefix=/usr, vaikka juuri todettiin, että ohjelma on asennettava debian/hello-alihakemistoon. Rivillä 69, kun ajetaan paketin asennuskomento, kuitenkin asetetaan kohdehakemistoksi debian/hello, jolloin paketti asentuu polkuun debian/hello/usr.
Jos tiedoston syntaksi on epäselvä, katso artikkeli Makefile. Paketti asennetaan monessa vaiheessa, aluksi riviltä 27 lähtien ajetaan configure-skripti config.status-osiossa. Tämän jälkeen ohjelma käännetään build-osiossa riviltä 34 eteenpäin.
build-indep-osiossa käännetään tai luodaan alustariippumattomat tiedostot. Hellon tapauksessa niitä ei ole. Riviltä 77 eteenpäin rakennetaan varsinaista alustariippuvaista binääripakettia. "dh_"-alkuiset rivit ovat debhelperin funktiokutsuja, jotka tekevät erilaisia pieniä operaatioita rakentaen pakettia. Mm. seuraavia funktioita on tarjolla:
- dh_testdir: Tarkistaa, että ollaan oikeassa hakemistossa
- dh_testroot: Tarkistaa, että meillä on pääkäyttäjän oikeudet kun niitä tarvitaan
- dh_strip: Ajaa strip-komennon suoritettaville tiedostoille, jolloin niiden koko pienenee
- dh_compress: Pakkaa gzipillä man-sivut ja ohjetiedostot, joiden koko ylittää 4kt
- dh_gencontrol: Luo binääripaketille control-tiedoston ja kopioi sen hakemistoon debian/hello/DEBIAN
- dh_md5sums: Luo MD5-tarkistussummat paketin tiedostoille
- dh_install: Jos ohjelma ei asenna kaikkia tarpeellisia tiedostoja oikeisiin hakemistoihin autoconfin avulla (esim. komennolla make install), voi käyttää tätä apufunktiota, jolle kerrotaan asennettavat tiedostot ja hakemistot debian/paketinnimi.install-tiedostossa.
Jos paketti ei käytä autoconfia, on rules muokattava sellaiseksi, että ohjelma kääntyy ja asentuu polkuun debian/paketinnimi. Se, miten kääntäminen tapahtuu, riippuu ohjelmasta. Funktion dh_install avulla asennetaan tiedostot oikeisiin hakemistoihin lopullisessa binaaripaketissa.
dirs
Tiedostossa debian/dirs luetellaan hakemistot, joiden pitää olla olemassa kun ohjelmaa asennetaan mutta joita ohjelma ei normaalin asennusprosessin aikana luo. Esimerkiksi /usr/bin on monesti tällainen.
dirs-tiedostossa hakemistot luetellaan omilla riveillään, ja ensimmäinen kauttaviiva jätetään pois. Hellon tapauksessa meille riittää kirjoittaa tähän tiedostoon rivi
usr/bin
.ex-päätteiset tiedostot
dh_make luo debian-hakemistoon monia .ex-päätteisiä tiedostoja. Näitä tiedostoja muokkaamalla on mahdollista esimerkiksi saada paketti lisäämään tehtäviä cronille ja kuvakkeen työpöytäympäristön valikkoon.
Oletuksena .ex-päätteisiä tiedostoja ei huomioida. Jos haluat käyttää niitä, muokkaa tiedosto ensin sopivaksi ja poista tiedostonimestä tämän jälkeen .ex-pääte. Lisäksi tarkista, että sopivaa funktiota kutsutaan rules-tiedostossa.
Poista ne .ex-tiedostot, joita et tarvitse. Hellon tapauksessa emme tarvitse näitä.
Tehdään paketti!
Nyt kun tarvittavat tiedostot on lopulta muokattu sopiviksi, on aika luoda varsinainen paketti. Siirry ohjelman päähakemistoon (hello-2.2) ja aja komento
dpkg-buildpackage -rfakeroot
joka tekee seuraavat asiat:
- Siistii paketin (ajaa makella komennon debian/rules clean)
- Kääntää ohjelman (debian/rules build)
- Luo binääripaketin (debian/rules binary)
- Allekirjoittaa .dsc-tiedoston gnupgllä
- Luo ja allekirjoittaa .changes-tiedoston
- Käyttää fakeroottia, jolloin pääkäyttäjän oikeuksia ei tarvita
Allekirjoitus vaatii, että olet luonut gpg:llä itsellesi avaimen. Tällöin sinulta kysytään avaimesi salasanaa.
Tämän jälkeen, jos kaikki sujui ilman virheitä, ylähakemistosta pitäisi löytyä seuraavat tiedostot:
- hello_2.2.orig.tar.gz - alkuperäinen lähdekoodi
- hello_2.2-1.dsc - gpg:llä allekirjoitettu control-tiedoston kaltainen tiedosto, jossa on listattu lähdekooditiedoston ja diff-tiedoston md5-summat
- hello_2.2-1.diff.gz - gzip-pakattu diff-tiedosto lähdekoodiin tehdyistä muutoksista
- hello_2.2-1_i386.deb - lopullinen deb-paketti!
- hello_2.2-1_i386.changes - gpg:llä allekirjoitettu tiedosto, joka sisältää paketin muutoslokin (debian/changelog) ja pakettiin liittyvien tiedostojen md5-summat
Nyt lopullinen paketti voidaan asentaa dpkg:llä:
dpkg -i hello_2.2-1_i386.deb
Kun myöhemmin teet muutoksia pakettiin, voit luoda uuden paketin nopeasti komennolla
fakeroot debian/rules binary
joka ei kuitenkaan käännä ohjelmaa alusta lähtien (tärkeää huomata, jos muutat lähdekoodia).
Lähdekoodipaketti
Edellä teimme tavallisen ns. binääripaketin, joka sisältää valmiiksi käännetyn ohjelman. Monesti on tarpeen tehdä myös lähdekoodipaketti, joka sisältää pakettiin ja sen kääntämiseen ja asentamiseen liittyvät tiedot (debian-hakemisto) ja ohjelman lähdekoodin. Tällöin paketti on mahdollista kääntää ja asentaa jokaiselle sopivalle alustalle kun taas käännetty .deb-paketti toimii vain yhdellä alustalla (esim. x86).
Lähdekoodipaketteja käytetään etenkin kun paketti julkaistaan esimerkiksi lisäämällä se jonkin jakelun virallisiin pakettilähteisiin. Tällöin kehittäjä yleensä vain lähettää palvelimelle lähdekoodipaketin, jonka palvelin sitten kääntää useille eri arkkitehtuureille.
Lähdekoodipaketti luodaan ajamalla paketin päähakemistossa komento
debuild -S -sa
Missä valitsin -S tarkoittaa, että luodaan lähdekoodipaketti ja -sa sisällyttää pakettiin mukaan alkuperäisen lähdekooditiedoston (.orig.tar.gz). Tällöin ylähakemistoon pitäisi ilmestyä samanlaisten tiedostojen kuin luotaessa binääripakettia, paitsi että varsinaista .deb-pakettia ei ilmesty.
Nyt lähdekoodipaketti koostuu näistä tiedostoista (paketti.dsc, paketti.orig.tar.gz ja paketti.diff.gz), ja sitä voidaan hallita esimerkiksi dpkg-source-ohjelmalla. Jos esimerkiksi olet saanut jostain lähdekoodipaketin, voit purkaa ja kääntää seuraavasti
dpkg-source -x paketti.dsc cd paketti dpkg-buildpackage -rfakeroot
Ilman debuildin -sa-valitsinta voi luoda paketin, joka ei sisällä alkuperäistä lähdekoodia. Tälle on käyttöä silloin, kun paketteja pidetään ulkopuolisessa pakettivarastossa ja uusi versio voidaan julkaista vain lähettämällä palvelimelle uusi lähdekoodipaketti ilman alkuperäistä lähdekoodia (kunhan alkuperäinen lähdekooditiedosto .orig.tar.gz ei ole muuttunut).
Lintian ja linda: onnistuiko paketti?
Lintian ja linda ovat ohjelmia, jotka tarkistavat tekemäsi paketin laadun. Molemmille ohjelmille annetaan parametrina pakettia luotaessa syntynyt .changes-päätteinen tiedosto. Yleensä kannattaa antaa niille myös valitsin -i:
lintian -i hello_2.2-1_i386.changes linda -i hello_2.2-1_i386.changes
Tulosteessa E:-alkavat rivit tarkoittavat virhettä, W:-alkavat varoituksia ja N:-alkavat huomautuksia.
Jos esimerkiksi et poistanut debian-hakemistosta .ex-päätteisiä tiedostoja, lintian ja linda varoittavat niistä. Yleensä paketin tulisi olla sellainen, etteivät lintian ja linda löydä niistä mitään valitettavaa.
Patchit
Joskus pakettia tehtäessä on tehtävä muutoksia myös itse ohjelman lähdekoodiin. Tällöin on siistiä pitää muutokset erillään patch-tiedostoissa. Kun binääripaketti sitten tehdään, otetaan patchit käyttöön ennen kääntämistä.
(Huomio! Debianin kehittäjien keskuudessa on keskusteltu patch-järjestelmien yhdenmukaistamisesta Debianin lähdekoodipaketeissa. Tässä artikkelissa esitetty tapa ei välttämättä ole suositeltava käytäntö, vaikka se sinänsä toimiikin. Aika paljon kannatusta on saanut esimerkiksi quilt-niminen patch-järjestelmä.)
Patchien hallintaan on monia aputyökaluja, mutta yksinkertaisimmillaan se hoituu näin:
- Pura alkuperäinen lähdekoodipaketti polkuihin /tmp/new ja /tmp/old
- Tee muutokset hakemistoon /tmp/new
- Aja hakemistossa tmp komento
diff -Nurp old new > 01_patchin-nimi
- Joka luo patchin tiedostoon 01_patchin-nimi (yleensä patchien edessä on numero, ja patchit otetaan käyttöön numerojärjestyksessä). Optiot -Nurp aiheuttavat sen, että diff ottaa huomioon myös uudet tiedostot (-N) ja käy hakemistot läpi rekursiivisesti (-r)
- Luo paketin debian-hakemistoon alihakemisto patches ja kopioi äsken luomasi patchi sinne (cp /tmp/01_patchin-nimi debian/patches/)
- Lisää debian/rules-tiedostoon seuraavat kohdat, jotka ottavat patchit käyttöön ennen ohjelman kääntämistä ja poistavat ne käytöstä hakemistoa "siivottaessa":
patch: patch-stamp
patch-stamp: dh_testdir # Oikea hakemisto # Kaikille .patch-päätteisille tiedostoille patches-hakemistossa @patches=debian/patches/*.patch; for patch in $$patches; do \ test -f $$patch || continue; \ echo "Applying $$patch"; \ patch -stuN -p1 < $$patch || exit 1; \ # Otetaan pathci käyttöön done touch $@ # Patchien poistaminen (ajettaessa make clean), palauttaa lähdekoodin alkuperäiseksi unpatch: dh_testdir @if test -f patch-stamp; then \ patches=debian/patches/*.patch; \ for patch in $$patches; do \ # Kerätään kaikki patchit reversepatches="$$patch $$reversepatches"; \ done; \ for patch in $$reversepatches; do \ test -f $$patch || continue; \ echo "Reversing $$patch"; \ patch -suRf -p1 < $$patch || exit 1; \ # Poistetaan patchi done; \ rm -f patch-stamp; \ fi
- Huolehdi siitä, että patch: ja unpatch: -kohdat ajetaan oikeaan aikaan: muuta rivi
build: build-stamp
- muotoon
build: patch-stamp build-stamp
Ja rivi
clean:
muotoon
clean: unpatch
Pbuilder
Pbuilder on järjestelmä, joka kääntää ja rakentaa paketit omassa pienessä chroot-järjestelmässä. Pbuilderia käytettäessä saavutetaan mm. seuraavat edut:
- Käännösaikaiset riippuvuudet (build-depends) asennetaan automaattisesti
- Paketti käännetään puhtaassa ja mahdollisimman yksinkertaisessa ympäristössä, johon ei ole asennettu mitään ylimääräistä. Näin varmistetaan, että paketin kääntäminen onnistuu kaikissa järjestelmissä ja että käännösaikaiset riippuvuudet ovat riittävät.
- Paketin voi kääntää eri jakeluille ja jopa eri arkkitehtuurille
Pbuilderin käyttö aloitetaan luomalla käännösympäristö komennolla (pääkäyttäjän oikeuksin)
pbuilder create
Komento luo tiedoston /var/cache/pbuilder/base.tgz, joka sisältää pakatun chroot-ympäristön. Ympäristön luominen kestää jonkin aikaa, sillä se lataa tarvittavat paketit palvelimelta, asentaa ne chroot-järjestelmään ja lopuksi pakkaa luodun järjestelmän.
Tämän jälkeen Pbuilderin vaatimat valmistelut on tehty ja paketit voidaan kääntää siinä ajamalla paketin hakemistossa komento pdebuild. Käännetty paketti löytyy hakemistosta /var/cache/pbuilder/result.
Pintaa syvemmälle
Monesti Pbuilderia halutaan käyttää luomaan paketteja muille jakeluille tai arkkitehtuureille (esimerkiksi 64-bittisessä Debianissa luodaan Pbuilderilla paketti 32-bittiselle Ubuntulle). Tätä varten on luotava chroot-ympäristöt kaikille näille jakeluille ja tehtävä muutamia asetuksia.
Tehdään seuraavaksi sellaiset asetukset, että voimme luoda paketteja sekä Debianin että Ubuntun eri versioille. Muut Debian-pohjaiset jakelut on mahdollista ottaa käyttöön samalla tavalla. Tehdään Pbuilderin asetukset lisäämällä tiedostoon ~/.pbuilderrc seuraavat rivit:
#Tarvittavia muuttujia : ${DIST:=$(lsb_release --short --codename)} : ${ARCH:=$(dpkg --print-architecture)} NAME="$DIST-$ARCH" DISTRIBUTION="$DIST" DEBOOTSTRAPOPTS=("--arch" "$ARCH" "${DEBOOTSTRAPOPTS[@]}") BASETGZ="`dirname $BASETGZ`/$NAME-base.tgz" BUILDRESULT="/var/cache/pbuilder/$NAME/result/" # Hakemisto luotaville paketeille APTCACHE="/var/cache/pbuilder/$NAME/aptcache/" case "$DIST" in intrepid|hardy|gutsy) # Ubuntu MIRRORSITE="http://fi.archive.ubuntu.com/ubuntu/" COMPONENTS="main restricted universe multiverse" ;; sid|lenny|etch) # Debian MIRRORSITE="http://ftp.fi.debian.org/debian/" COMPONENTS="main contrib non-free" ;; *) echo "Unknown distribution: $DIST" exit 1 ;; esac
Jolloin Pbuilder tunnistaa käytettävän jakelun DIST-ympäristömuuttujasta ja arkkitehtuurin ARCH-ympäristömuuttujasta. Jos ympäristömuuttujille ei erikseen anneta arvoja, käytetään nykyisen järjestelmän tietoja.
Nyt voimme luoda chroot-ympäristöt eri jakeluille määrittelemällä tarvittavat ympäristömuuttujat, esimerkiksi 32-bittiselle Debian Sidille (Debianin kehitysversio) luodaan ympäristö komennolla (pääkäyttäjänä)
DIST=sid ARCH=i386 pbuilder create
Kun halutut ympäristöt on luotu, voidaan paketit kääntää tässä ympäristössä käyttäen samoja ympäristömuuttujia, esimerkkitapauksessamme
DIST=sid ARCH=i386 pdebuild
Luotu paketti löytyy hakemistosta /var/cache/pbuilder/sid-i386/.
Muut pakettityypit
Multi-binary: Monta pakettia yhdestä lähdekoodipaketista
Joskus tulee eteen tilanne, jossa yksi ohjelma on jaettava useampaan eri pakettiin. Tällainen tilanne tulee eteen mm. silloin, kun paketoidaan suurta peliä: yleensä peleissä itse käännetty ohjelma vie murto-osan siitä tilasta, jonka pelin datatiedostot vievät. Jos koko ohjelma laitettaisiin yhteen pakettiin, käytettäisiin turhaan palvelimen levytilaa ja resursseja, kun samat alustariippumattomat datatiedostot kopioitaisiin jokaiselle arkkitehtuurille tehtyyn pakettiin.
Toinen esimerkki tilanteesta, jossa ohjelman jakaminen moneen pakettiin on järkevää on ohjelma, jonka mukana tulee paljon (esimerkiksi jopa kymmeniä megatavuja) dokumentaatiota ja ohjeita.
Debhelper mahdollistaa useampien pakettien luomisen yhdestä lähdekoodipaketista varsin yksinkertaisesti. Ensinnäkin jokaiselle paketille kirjoitetaan oma osio debian/control-tiedostoon. Tiedostoon tulee aluksi normaalisti lähdekoodipaketin tiedot, ja tämän jälkeen luotavien binääripakettien tiedot peräkkäin. Esimerkki:
Source: hello Section: unknown Priority: extra Maintainer: Ylläpitäjä <sähkö@ơsti> Build-Depends: debhelper (>= 5), autotools-dev Standards-Version: 3.7.3 Package: hello Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Recommends: hello-doc Description: Hello-ohjelma Klassinen hello-ohjelma, joka tulostaa tekstin hello world. Package: hello-doc Architecture: all Depends: hello Description: Hellon ohjeet Monipuoliset käyttöohjeet hello world -sovelluksen käyttöön.
Tämän jälkeen muutetaan paketin asentamista (debian/rules) siten, että esimerkiksi pakettiin hello kuuluvat tiedostot asennettaisiin hakemistoon debian/hello/ ja paketin hello-doc-tiedostot hakemistoon debian/hello-doc. Näihin hakemistoihin tiedostot asennetaan kuten normaalisti luotaessa vain yhtä pakettia, eli esimerkiksi ajettavat ohjelmat voitaisiin sijoittaa polkuun debian/hello/usr/bin/.
Tällaisessa tilanteessa ei yleensä ole järkevää käyttää dirs-tiedostoa luomaan samat hakemistot molempiin paketteihin, koska luultavasti samoihin hakemistoihin ei sijoiteta tiedostoja eri paketeissa. Sen sijaan voidaan käyttää pakettikohtaisia tiedostoja, esimerkiksi hello.dirs ja hello-doc.dirs.
Jos jokin Debhelperin komento (muotoa dh_jotain) halutaan rules-tiedostossa ajaa vain tietylle paketille, voidaan käyttää valitsinta --package, esimerkiksi komennolla
dh_installinfo --package=hello
asennettaisiin info-tiedostot vain hello-pakettia luotaessa.
CDBS
Edellä tehtiin paketti käyttäen Debhelperiä, jolloin rules-tiedoston kirjoittaminen oli hyvinkin työlästä. CDBS (Common Debian Build System) on toinen lähestymistapa pakettien luomiseen: sitä käytettäessä Autotoolsia käyttävän paketin rules-tiedosto vaatii vain 4 riviä!
CDBS on modulaarinen apuohjelma paketin tekemiseen. Sitä käytettäessä rules-tiedostossa sisällytetään halutut moduulit, jotka hoitavat esimerkiksi pakettin kääntämisestä ja patchien käyttöönotosta. Ideana on, että monissa paketeissa samoina toistuvat osiot (esim. paketin kääntäminen ja patchien käsittely) on siirretty yhteen paikkaan, eikä niitä tarvitse aina kirjoittaa uudestaan.
CDBS:ää käytettäessä paketin käännösaikaisiin riippuvuuksiin on lisättävä cdbs.
Esimerkiksi edellä paketoimamme hello-ohjelman rules-tiedostona riittäisi seuraava:
#!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk
Kuten huomaat, CDBS:ää käytetään sisällyttämällä .mk-päätteisiä Makefile-tiedostoja. Näitä tiedostoja tulee CDBS:n mukana useita ja niitä voi asentaa myös muista paketeista lisää (jolloin kyseinen paketti on lisättävä käännösaikaiseksi riippuvuudeksi).
Eräitä CDBS:n .mk-tiedostoja ovat:
Tiedosto | Kuvaus |
rules/debhelper.mk | Käyttää Debhelperiä tarvittavissa kohdissa |
rules/dpatch.mk rules/simple-patchsys.mk |
Patch-järjestelmiä |
class/autotools.mk | Käyttää Autotoolsia tarvittavissa kohdissa |
class/gnome.mk | Rakentaa paketin GNOME-ohjelmalle |
class/kde.mk | Rakentaa paketin KDE-ohjelmalle |
class/python-distutils.mk | Python-ohjelmien paketointiin |
CDBS:n kanssa ei kuitenkaan tarvitse rajoittua vain .mk-tiedostoihin. Jos vaikkapa asennuksen aikana on tehtävä joitain harvinaisempia toimenpiteitä, ne voidaan lisätä rules-tiedostoon hieman samaan tyyliin kuin käytettäessä debhelperiä. Esimerkiksi jos paketin hello asennuksen yhteydessä on muutettava jonkin tiedoston oikeuksia, se onnistuu lisäämällä rules-tiedostoon kohta
binary-install/hello:: chmod o+x /usr/bin/hello
Mahdollisia kohtia ovat mm.
Toiminto | Suoritus |
binary-install/paketti:: | Paketin luomisen yhteydessä |
build/paketti:: | Kääntämisen yhteydessä |
clean:: | Siivottaessa käännöshakemistoa |
Patchit
Kuten edellä jo mainittiin, CDBS helpottaa myös patchien käyttöä. Sen mukana tulee useita erilaisia .mk-tiedostoja, jotka toteuttavat hieman erilaiset patch-järjestelmät.
Simple patchsys on nimensä mukaisesti yksinkertainen patch-järjestelmä. Sitä käytettäessä ennen lähdekoodin kääntämistä otetaan käyttöön hakemistossa debian/patches olevat patchit aakkosjärjestyksessä (yleensä tiedostot ovat nimeltään muotoa numero-nimi.patch, esim. 10-korjaa_makefile.patch, jolloin ne otetaan käyttöön numerojärjestyksessä). Myöskään sillä ei ole väliä, kuinka monta polkua patchin tiedostopoluista on jätettävä huomiotta (patchin valitsin -p), sillä simple patchsys yrittää eri tasoja, kunnes patchin käyttöönotto onnistuu. Myös patchien poistaminen lähdekoodista siivouksen (clean) yhteydessä tapahtuu automaattisesti.
Simple patchsys otetaan käyttöön lisäämällä rules-tiedostoon rivi
include /usr/share/cdbs/1/rules/simple-patchsys.mk
Järjestelmään kuuluu myös cdbs-edit-patch-työkalu, joka mahdollistaa patchien luomisen ja muokkaamisen interaktiivisesti. Esimerkiksi jos haluamme luoda uuden patchin tai muokata vanhaa, jonka nimi on 10-korjaa_makefile.patch, se onnistuu seuraavasti:
- Ajetaan komento cdbs-edit-patch 10-korjaa_makefile.patch, jolloin CDBS luo projektihakemistosta väliaikaisen kopion, johon ottaa käyttöön kaikki luotavaa patchia aiemmin käyttöön otettavat patchit (joiden numero on pienempi kuin 10). Jos tällä nimellä on jo patchi olemassa, otetaan myös se käyttöön.
- CDBS siirtää komentorivin tähän väliaikaiseen hakemistoon, jonka tiedostoja voidaan nyt muokata aivan normaalisti esimerkiksi vimillä. Tehdään tässä tilassa halutut muutokset.
- Poistutaan väliaikaisesta työskentelytilasta näppäinyhdistelmällä Ctrl+D. CDBS luo uuden patchin debian/patches-hakemistoon (tai päivittää vanhaa, jos muokkasimme jo olemassa olevaa patchia) ja palaa takaisin projektihakemistoon.
- Nyt luotu patchi on normaalisti käytössä kun pakettia käännetään.
Lisätietoja
Aiheesta muualla
- Debian New Maintainers' Guide
- Debian policy - Debianin käytäntöjä ja sääntöjä
- Ubuntun PackagingBasics-opas
- Ubuntu Packaging Guide
- Setting up your own APT reposity