Következő Előző Tartalomjegyzék Kilépés

10. De mégis hogyan...?

A száraz doksihoz képest ez a fejezet megpróbál inkább gyakorlatiasabb lenni... Bár sajnos ez a hozzáállás csak a csomagkészítés egyes kiemelt mozzanataira működik, a teljes csomagkészítési folyamathoz nem árt megnézni sok-sok csomagot, és átolvasni a doksit is.

10.1. acquire

Erről kéne tisztességes doksi... Ehelyett csak egy tipp: egy-két agyament progi úgy van becsomagolva, hogy a tar fájlban minden útvonal "./" kezdetű. Ez a "tar tzf fájlnév" parancs hatására, vagy mc-ben F3-ra jól látszik. Ilyenkor a kicsomagolandó könyvtár nevét is "./" kezdettel kell megadnunk.

10.2. compile

Csomó progi, amelyik hoz magával library-t, a libtool csomagot használja ennek elkészítéséhez. A libtool valami autoconf-automake jellegű gány, tehát a lefordítandó csomagban is van egy ehhez tartozó ltmain.sh, meg a telepített rendszer libtool csomagjában is van ilyen. Sajnos a progi úgy szar és bugos, ahogy van. Ezért a disztribben egy agyon patchelt változat van. Rengeteg progi csak akkor fordul le jól, ha a libtoolt előbb kicseréljük a rendszerben lévőre.

Az ub_configure szkript erről szól. Ez két dolgot csinál. Az egyik az, hogy a ./configure-t hívja meg standard opciókkal. A másik, hogy előtte-utána a libtoolt kicseréli.

Ha nem akarjuk kicserélni a libtoolt (van néhány progi, amelyik csak a saját magával adott libtoollal fordul le, az általunk felülcsapottal nem), akkor az UB_SKIP_UPDATELIBTOOL változót állítsuk be nem-üres értékre, így indítsuk az ub_configure szkriptet.

A make fázis helyett ajánlott az ub_make szkript hívása.

10.3. install

A telepítés során a legnehezebb kérdés, hogy hogyan tudjuk nem a végleges helyére telepíteni a szoftvert.

A legfontosabb, hogy minden esetben nézzünk rá a csomagban lévő Makefile-ra (vagy Makefile.in-re), ennek is "install:" fejezetére, és nézzük meg, hogy van-e valami változó (általában DESTDIR, néha ROOTDIR vagy hasonló), amely egyetlen változót elég beállítani. Vigyázzunk, sok esetben az "install:" fejezet nem telepít ténylegesen, hanem csak rekurzíve meghívja az alkönyvtárak alatti "make install"-t, így a valamelyik alkönyvtár alatt lévő Makefile.in adhat tippet arról, hogy van-e ilyen változó.

Az automake segítségével generált Makefile.in-ek mind használják a DESTDIR-t. Tehát ha van Makefile.am, akkor ez tuti jó lesz. Ha nem, akkor is simán lehet jó (ezt a fájlt nem mindenki csomagolja be). A Makefile.in első sorában lévő automake-hivatkozás is árulkodó lehet.

Ha a Makefile.in-t nem az automake készítette, akkor is lehet, sőt, igen gyakran van ilyen változó, nézzük meg.

Ha találunk ilyen változót, mindenképpen ezt az egy változót használjuk. Csak végszükség esetén válasszuk azt a megközelítést, hogy a prefix, mandir, bindir, infodir satöbbi változókat egyenként felülbíráljuk.

A fentiek kivitelezésében az ub_makeinstall szkript segíthet. Ez megtippeli, hogy működik-e a DESTDIR (teszi ezt úgy, hogy megnézi, hogy a Makefile.in első sorában van-e hivatkozás az automake progi >= 1.4 verziójára). Ha van, akkor egy "make DESTDIR=${UB_INSTALLDIR} install" parancsot hajt végre, ha viszont nem, akkor egy "make prefix=... mandir=... infodir=... install" parancsot.

Az automatikus tippelésről lebeszélhetjük az ub_makeinstall szkriptet, ha az UB_USE_DESTDIR változót "no" vagy "yes" értékre állítjuk. "no" értékre valószínűleg sosem kell állítani, mert az automake-generálta Makefile.in-ek mind jól használják a DESTDIR-t. "yes" értékre akkor érdemes (olvasd: kell) állítani, ha a Makefile.in vagy Makefile támogatja a DESTDIR-t, de nem az automake generálta azt.

Ha a kézzel írott Makefile.in vagy Makefile valami hasonló másik változót használ (mondjuk ROOTDIR-t), akkor az ub_makeinstall szkriptet nem tudjuk használni, helyette írjuk azt, hogy "make ROOTDIR=${UB_INSTALLDIR} install".

10.4. doc

A csomag forrásából az esetleg hasznos doksifájlok neveit írjuk le. Lehetőleg csak plaintext és html fájl legyen köztük, esetleg ps vagy pdf, de semmiképp se valami feldolgozásra váró formátum (sgml, tex, groff). Továbbá példa konfig fájlok vagy példa szkriptek is mehetnek.

Ami hasznos: leírás a progiról, elérhetőség, szerző, honlap címe, changelog, todo, bugs, licenc.

Ami nem hasznos, nem idevaló: hogyan fordítsuk a progit (általában INSTALL, de sokszor a README is), Linuxtól különböző oprendszerekről szóló leírás (README.W32, README.AIX, README.HPUX stb.), ABOUT-NLS, régóta nem karbantartott changelog, stb.


Következő Előző Tartalomjegyzék Kilépés