Slackware Linux - csomagkezelés 1.

rész

(Polesz 2016. január 7., csütörtök - 23:12)

http://hup.hu/node/144964

A Slackware Linux mint a többi Linux disztribúció tartalmaz a csomagkezeléshez nélkülözhetetlen

eszközöket. A régebbi időkben a csomagok kiterjesztése .tgz volt, de az utóbbi időben ez változott
és már .txz az alapértelmezett. A csomagkezelő a pkgtools névre hallgat. Ez tartalmaz több elemet,
mint a csomagok telepítéséhez használt installpkg, frissítéshez az upgradepkg, eltávolításhoz
removepkg és saját csomag készítéséhez a makepkg sh alapú szkriptfájlokat. Igen, a Slackware
csomagkezelés alapja sh szkriptekben van megírva. Ezt ellenőrízhetjük a /sbin/ könyvtárban lévő
szkriptek tanulmányozása alapján. A telepített csomagok információi a /var/log/packages
könyvtárban helyezkednek el. További használt könyvtárak: /var/log/scripts, /var/log/removed-
packages, /var/log/removed-scripts.

Tehát minden adott ahhoz hogy tudjunk csomagokat telepíteni, frissíteni, eltávolítani. Egy valamit
azonban nem tud: függőséget kezelni! Tudom most sokan akik deb, rpm rendszereken nőttek fel
most a szívükhöz kapnak. Azonban nem ilyen vészes a helyzet :) A Slackware alapfilozófiája szerint
minden csomag ami a rendszerhez szükséges adott a megfelelő könyvtárakban. Egy alap telepítés
során az alábbi könyvtárak találhatóak a telepítő lemezen: a/ ap/ d/ e/ f/ k/ kde/ kdei/ l/ n/ t/ tcl/ x/
xap/ xfce/ y/. Ahhoz, hogy egy működő rendszert tudjunk telepíteni legfontosabb az a/ ami a base
(alap) csomagokat tartalmazza, az n/ network (hálózat) kezeléséhez szükséges.

A csomagok felépítése nagyban eltér a deb és rpm rendszereken használtakhoz képest. Itt minden
program egy csomag. Nincs külön szedve bin lib dev részekre. Minden egyes csomag tartalmazza
az összes futtatható állományát, konfigurációkat, adatokat, libeket és a fordításhoz szükséges
fájlokat (/usr/include/...). Ennek köszönhetően a csomag nincs szétaprózva, tehát ha a gtk2
csomagot feltelepítettem akkor ha fordítani szeretnék bármilyen gtk2-öt használó programot, akkor
az ehhez szükséges fájlokat mind megtalálom nem kell külön keresni a fejlesztéshez szükséges
csomagot. Ennek természetesen az az eredménye, hogy minden csomag jóval nagyobb, viszont a
csomagok száma jóval kisebb mint a már említett rendszereken.

Egy slackware csomag felépítése tehát mindent tartalmaz amit a program fejlesztői szükségesnek
látnak nem csak a minimális futtatáshoz hanem a későbbi fejlesztésekhez is. A csomagok
szabványos eszközökkel szétbonthatóak, átnézhetőek. Elég a tar parancsot ismerni hozzá ;-)

Nézzük egy konkrét példát a csomag felépítésére:

A pkgtools csomag felépítése:

install/
install/doinst.sh
install/slack-desc
sbin/
sbin/explodepkg
sbin/installpkg
sbin/makepkg
sbin/pkgtool
sbin/removepkg
sbin/upgradepkg
usr/
usr/man/
usr/man/man8/
usr/man/man8/explodepkg.8.gz
usr/man/man8/installpkg.8.gz
usr/man/man8/makepkg.8.gz
usr/man/man8/pkgtool.8.gz
usr/man/man8/removepkg.8.gz
usr/man/man8/upgradepkg.8.gz
var/
var/log/
var/log/setup/
var/log/setup/setup.70.install-kernel
var/log/setup/setup.80.make-bootdisk
var/log/setup/setup.htmlview
var/log/setup/setup.services
var/log/setup/tmp/

Az install könyvtár minden esetben a csomagkezelőhöz tartozó információkat tartalmazza, a többi

könyvtár és fájl a helyére kerül a fájlrendszeren belül. Egy csomagtelepítés közben a pkgtools
ellenőrzi az install/ könyvtárban lévő fájlokat. Átnézi a már rendszerben lévőeket és összehasonlítja
a csomagban lévővel. Egy frissítés közben minden esetben összeszedi azokat a fájlokat és
könyvtárakat amire már nem lesz szükség. Ezeket törölni fogja telepítés után. Az install/ könyvtáron
belül a slack-desc fájl tartalmazza a csomag leírását. Ez nem kötelező elem, de ajánlott! Enélkül is
lehet élni, de nem érdemes :-) A doinst.sh szkript pedig telepítés után fog lefutni. Ez rakja helyére a
szimbolikus linkeket és hajt végre több változtatást is ha szükséges. Ez hasonló a debian által
használt pre-inst, post-inst szkriptekhez.

Fontos megjegyezni, hogy nem mindent végez el a csomagkezelő! Egy kernel frissítés után a lilo
vagy grub frissítést magunknak kell elvégezni különben kereshetünk egy másik rendszert hogy
helyreállítsuk az elrontott rendszerbetöltőt. Lilo használata esetén minden esetben érdemes kernel
frissítés után a lilo -v parancsot kiadni.

Az ap/ könyvtárban általánosságban olyan alkalmazások találhatóak amik nem szükségesek a

rendszer futásához, de megkönnyítik a mindennapokat. Ezek mind konzolban futó programok. Itt
található a slackpkg csomag is aminek segítségével akár hálózaton keresztül is tudjuk frissíteni a
rendszerünket. Hasonlóan a Debian rendszereken meglévő apt-get programhoz. Lényeges
különbség azonban, hogy egyszerre csak egy mirrort használhatunk, tehát nem lehet további
forrásokat hozzáadni, és a függőségeket ez sem kezeli. Tulajdonképpen egy előtét program a
pkgtools használatához.

A slackpkg használata előtt be kell állítani egy mirrort ahonnét szeretnénk a rendszerünket frissíteni.
Ez a fájl a /etc/slackpkg/mirrors fájlban található. Érdemes egy hozzánk közel esőt választani. Én
személy szerint a lengyel ftp.slackware.pl-t javaslom. A slackpkg használata nagyon egyszerű.
Beállítod a mirrort, elindítod a csomagok állományának frissítését: slackpkg update, majd
slackpkg upgrade-all. Érdemes áttanulmányozni a slackpkg szkriptet, de aki ismeri az apt-get
felépítését ezt sem fogja nehezebbnek találni.

A slackpkg azonban nem csak abban segít, hogy csomagokat telepítsünk, hanem a megváltozott
konfigurációs fájlokat is kezelni tudjuk segítségével. Ehhez csak el kell indítani egy frissítés után a
slackpkg new-config parancsot. A Slackware csomagkezelő minden olyan csomagban ami a /etc
alatt tartalmazza a saját konfigurációs fájljait alapértelmezetten nem cseréli le az új változatra.
Egyszerűen az új konfigurációs állomány létrejön a régi mellett a .new kiterjesztéssel. A new-config
ezeket a fájlokat keresi meg és utána mi magunk határozhatjuk meg, hogy mi legyen ezekkel a
fájlokkal. Felülírhatjuk a régit, törölhetjük, összehasonlíthatunk. Például VirtualBox telepítése után
alapból a /etc/rc.d/rc.local fájlban fogja beleírni magát, hogy rendszerindításkor lefusson. Ha a
Slackware csomag új verziója tartalmazza az új rc.local fájlt akkor ha ezt felülcsapná egyből akkor
rakhatnánk be kézzel újra, hogy fusson rendszerindítás után a vbox.

De nincs függőségkezelés! Nincs. Még mindig nincs. Azonban a Slackware ettől még nem
használhatatlan. A /l könyvtár tartalmaz szinte minden libet ami szükséges a programok
futtatásához. Itt található az Xfce-hez szükséges GTK könyvtár fájlok, a KDE futásához szükséges
Qt könyvtár is. Aki frissen ismerkedik a rendszerrel annak érdemes a teljes /l könyvtárat felrakni.
Későbbiekben amikor már ismered a rendszert könnyen tudsz szelektálni, hogy mi kell és mi nem.
Ha egyszerűen csak használni akarod akkor feltelepíted mindet. Abból még nem volt baja senkinek.

Bármelyik programod ami úgy tűnik, hogy nem fut indítsd el egy terminálban. Ha itt kiírja, hogy
mire van szüksége akkor megkeresed azt a csomagot ami az adott libet tartalmazza. Feltelepíted és a
program futni fog. Ez általában csomagok frissítése után fordulhat elő. Amikor új csomagok
kerülnek a rendszerbe. Frissítés előtt érdemes elolvasni a Changelog fáljt.

Egy ilyen részlet:

d/Cython-0.23.4-x86_64-1.txz: Added.
Cython is required to build blueman.
kde/bluedevil-2.1.1-x86_64-3.txz: Rebuilt.
l/M2Crypto-0.22.5-x86_64-1.txz: Upgraded.
l/djvulibre-3.5.27-x86_64-1.txz: Upgraded.
l/fuse-2.9.4-x86_64-1.txz: Upgraded.
l/glibc-2.22-x86_64-3.txz: Rebuilt.
Fixed empty /etc/nscd.conf.new. Thanks to Jakub Jankowski.
l/glibc-i18n-2.22-x86_64-3.txz: Rebuilt.
l/glibc-profile-2.22-x86_64-3.txz: Rebuilt.

A függőség kezelés nem léte miatt a Cython csomag nem fog feltelepedni magától. Természetesen
rá tudod venni a slackpkg-t, hogy az új csomagokat is telepítse. Azonban alapértelmezés szerint
nem teszi. Sőt ha egy csomag megváltozik azt sem figyeli. Jó példa erre a syslog -> syslog-ng csere.
A 14.1 még a régebbi syslog csomagot tartalmazza, azonban a current ágban már a syslog-ng
csomag van. A slackpkg segítségével ezt is le tudod cserélni, de nem alapértelmezetten!

Most már tudunk csomagokat telepíteni, frissíteni. A rendszerünk kész arra, hogy belakjuk. Mi
történik azonban ha olyan csomagot szeretnénk ami nem a rendszerünk része? Erre ad választ a
második rész.
 Slackware Linux - csomagkezelés 2. rész

(Polesz 2016. január 8., péntek - 12:36)

http://hup.hu/node/144971

Mi tehetünk ha olyan programot szeretnénk telepíteni, használni ami nem érhető el a Slackware
tárolóban? Erre többféle módszer is létezik. Szerintem nem fogom tudni mindet felsorolni, de
megpróbálom érinteni a legtöbb lehetőséget.

0. A Slackware csomag nevének felépítése

1. Más rendszer csomagjának használata
2. Nem hivatalos Slackware tárolók használata
3. Forrásból telepítés

0. A Slackware csomag nevének felépítése

Minden egyes Slackware csomag az alábbi séma szerint épül fel:

programneve-verziószám-architektúra-build.txz

Az architektúra x86-os környezetben az alábbiak lehetnek: i686, x86_64, noarch. Az első a 32, a
második a 64 bites, a harmadik az architektúra független csomagok jelölése. Értelemszerűen i686-
os rendszeren ne használjuk a 64 bites rendszer csomagjait és fordítva (kivéve multilib, de erről
később). A független csomagokat bármely rendszeren telepíthetjük. Ezek általában szkriptnyelven
megírt csomagok. Ilyen például a pkgtools csomag is. A build szám jelzi, hogy hányadik fordításnál
járunk anélkül hogy a csomag verziószáma emelkedett volna. Ez akkor szükséges ha például új
libeket viszünk a rendszerbe és a programot ennek segítségével újrafordítjuk. A Changelog fájl
tanulmányozása során elég sor rebuild sort láthatunk. Ezen csomagok build száma fokozatosan
emelkedik. Itt azonban nem csak számokat használhatunk. A rendszer csomagok frissítése során
általában 1_slack14.1. Ez a current ágra nem vonatkozik, itt folyamatosan frissülnek a csomagok.

1. Más rendszer csomagjának használata

Ez a módszer a legegyszerűbb, de egy kis odafigyelést azért igényel. Ha olyan programot

szeretnénk használni ami nincs meg csak mondjuk .deb csomagban ne essünk kétségbe! Töltsük le a
.deb állományt és varázsoljuk át Slackware csomaggá. Példánkban használjuk a PergerSoft
QtSmartStorage programját. A letöltött csomagot az

ar x qtsmartstorage_1.2.1_amd64.deb

Ekkor a szétbontott .deb állomány mellett az alábbi fájlokat fogjuk találni: control.tar.gz, data.tar.gz
(újabban .xz), debian-binary. Ebből a leglényegesebb állomány a data.tar.gz ami magát a programot
tartalmazza minden alkotóelemével együtt.
Csináljuk egy pkg/ könyvtárat, lépjünk be és bontsuk ki az előzőleg kibontott data.tar.gz állományt:

mkdir pkg
cd pkg
tar xf ../data.tar.gz

Ahhoz, hogy a csomagkezelő tudja, hogy pontosan milyen csomagot készítünk írjuk meg az
install/slack-desc állományt:

mkdir install
nano install/slack-desc

A slack-desc fájl felépítése roppant egyszerű. Minden sor a csomag nevével kezdődik majd
kettőspont és a leírás.

qtsmartstorage: QtSmartStorage - Számlázó rendszer / Hungarian Invoice

System
qtsmartstorage:
qtsmartstorage: Magyar Számlázó rendszer / Hungarian Invoice system.
qtsmartstorage: Telepítés után választhatunk, hogy SQLite, PostgreSQL
vagy MySQL adatbázissal
qtsmartstorage: kívánjuk a programot használni.
qtsmartstorage: Számlákra egyedi LOGO-t helyezhető el. Az elkészült
számlák másolhatóak.
qtsmartstorage: Számlaminták alapján folyamatos szolgáltatás számlázható.
qtsmartstorage: Folyamatosan bővülő számlaformátumok.
qtsmartstorage:
qtsmartstorage: Website: http://pergersoft.hu
qtsmartstorage:

A csomagra vonatkozó leírást jelen esetben a control.tar.gz állományból kivarázsolhatjuk. A control

fájlban található Description: sor utáni részek leírják, hogy mire is való az adott csomag. Mi
magunk is megírhatjuk, de jobb a készítők által kitalált szöveget használni megkímélve magunkat a
weboldalra mászkálástól, kereséstől. Ha ezzel jól meg vagyunk akkor már csak a csomagkészítés
van hátra:

makepkg -l y -c y ../qtsmartstorage-1.2.1-x86_64-1.txz

A makepkg paraméterezéséhez olvassuk el a manuálját, vagy csak simán indítsuk el a makepkg

programot és nézegessük mind a 3 paraméterét. Ami fontos, hogy azonos könyvtárba nem tudjuk a
csomagot elkészíteni ezért is használtam a ../ tagot a csomag neve előtt.

Ezután a csomagot már tudjuk az installpkg program segítségével telepíteni, ha már volt ilyen
csomagunk, akkor az upgradepkg segítségével frissítsük. Fontos megjegyezni, hogy az ilyen
csomagok nem 100%, hogy működni fognak a rendszereden, mert a különböző libek másként
lehetnek fordítva. Szerencsére a QtSmartstorage szépen működik csak a Qt5 csomag telepítésére
van szükség hozzá, ami nincs a rendszertárolókban (egyelőre).

2. Nem hivatalos Slackware tárolók használata

Ahhoz hogy ilyen tárolókat használni tudjunk fel kell telepíteni a slapt-get programot. A program
honlapja: http://software.jaos.org/. Innét rögtön Slackware csomag formátumban le is tölthetjük.
Telepítsük fel az installpkg segítségével. A /etc/slapt-get/slapt-getrc fájlban válasszunk mirrort
ugyanúgy mint a slackpkg használata során. Ennél a programnál az apt-get-hez hasonlóan azonban
több csomagtárolót is fel tudunk venni. Ezeket külön-külön be tudjuk állítani, hogy milyen
sorrendben legyenek használva. A csomagtároló után lévő :OFFICIAL, :CUSTOM, :PREFFERED
címkék ennek beállítására szolgálnak.

# Working directory for local storage/cache.

WORKINGDIR=/var/slapt-get

# Exclude package names and expressions.

# To exclude pre and beta packages, add this to the exclude:
# [0-9\_\.\-]{1}pre[0-9\-\.\-]{1}
EXCLUDE=^aaa_elflibs,^devs,^glibc-.*,^kernel-.*,^udev,.*-[0-
9]+dl$,i[3456]86

# Base url to directory with a PACKAGES.TXT.

# This can point to any release, ie: 9.0, 10.0, current, etc.

SOURCE=http://ftp.slackware.pl/pub/slackware/slackware64-
current/:OFFICIAL
#SOURCE=ftp://mirror.netcologne.de/slackware/slackware64-
current/:OFFICIAL
#SOURCE=http://mirror.oss.maxcdn.com/slackware/slackware64-
current/:OFFICIAL
#SOURCE=ftp://ftp.slackware.at/slackware64-current/:OFFICIAL

# Sources for the testing, extra, and pasture areas - if you use them.
# SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware64-
14.1/extra/:OFFICIAL
# SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware64-14.1/testing/
# SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware64-14.1/pasture/

# Source for slapt-get.

#SOURCE=http://software.jaos.org/slackpacks/14.1-x86_64/:OFFICIAL

# Packages on a CD/DVD.
# SOURCE=file:///mnt/cdrom/:OFFICIAL

# Home made packages.

# SOURCE=file:///var/www/packages/:CUSTOM

# Multilib support
SOURCE=http://slackware.org.uk/people/alien/multilib/:PREFERRED

A slapt-get --update frissíti a csomagok listáját, a --upgrade pedig meghatározza a frissítendő

csomagok listáját és telepíthetjük ezeket a csomagokat.
Ha sok-sok csomagra van szükségünk akkor a slapt-get forrásokhoz vegyük fel a http://slacky.eu
forrását és már is használhatunk rengeteg programot:

SOURCE=http://repository.slacky.eu/slackware64-14.1/:CUSTOM

A slapt-get program párja a slapt-src, ami szintén a jaos.org honlapon található. Ennek segítségével
forrásból tudjuk a csomagokat telepíteni. Ugyanúgy állítsuk be a forrást a /etc/slapt-get/slapt-srcrc
fájlban:
# preferred mirror
SOURCE=http://www.slackware.org.uk/slackbuilds.org/14.1/
BUILDDIR=/usr/src/slapt-src
PKGEXT=txz

A slapt-src -u, után keressünk egy számunkra szimpatikus programot és ha készült hozzá slackbuild
fájl akkor le tudjuk tölteni és a gépünk fordítás után feltelepíti nekünk a csomagot. A
http://www.slackbuilds.org/ oldalon kereshetünk a csomagok között, hogy a számunkra fontos
csomag megtalálható-e.

A slapt-get és a slapt-src már függőség kezeléssel is fel van vértezve, de sajnos előfordul, hogy
egyes csomagok még sem telepítik azokat amikre szükségük lenne. Ilyenkor kézzel kell besegíteni
és előbb lefordítani a függőséget, utána a programot. A slapt-src egyik nagy hátránya, hogy a saját
gépünkön fogja a fordítási munkát elvégezni, ezért ha nem elég gyors a gép akkor bizony akár
órákig is eltarthat egy-egy művelet.

3. Forrásból telepítés

Az egyik legidőigényesebb művelet és nagyon sok részből áll össze. Ezért ez a fejezet a következő
3. részben lesz bővebben kifejtve.
 Slackware Linux - csomagkezelés 3. rész

(Polesz 2016. január 9., szombat - 19:34)

http://hup.hu/node/144992

3. Forrásból telepítés

Az egyik legjobb, és legteljesebb módszer, hogy csomagokat telepítsünk a rendszerünkre. Fordítás

során szinte mindent testre szabhatunk és a program azokkal a beállításokkal telepedik amit mi
szeretnénk. Természetesen ez olyan programokra vonatkozik ahol sok-sok mindent be tudunk
állítani a fordítás folyamán. Ez viszont nagyon időigényes tud lenni, kisebb gépeken nem javasolt
nagyobb méretű programok fordítása. Régebben simán kivártam egy 1 napos fordítást is, de az idő
pénz, ezért inkább egy nagyobb gépet használok a fordításhoz és az elkészített csomagokat
terjesztem a gépeimen.

A legegyszerűbb módszer: letöltjük a forrást a program honlapjáról és kiadjuk az alábbi

utasításokat:

./configure
make
make install

Ez így nagyon egyszerűnek hangzik és az is, de ezzel van egy pár probléma. Semmit nem
állítottunk be és telepítés után minden a /usr/local könyvtárba kerül (nem feltétlenül, függ a
configure szkript alapbeállításaitól). Ahhoz hogy tudjuk mit és hogyan lehet beállítani a fordítás
során érdemes a configure szkriptet először átnézni.

./configure --help

Egy rövid részlet az spkg program configure kimenetéből:

...
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data
[PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
...
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-static[=PKGS] build static libraries [default=yes]
--enable-fast-install[=PKGS]
optimize for fast installation [default=yes]
--disable-libtool-lock avoid locking (might break parallel builds)
--enable-dependency-tracking
do not reject slow dependency extractors
--disable-dependency-tracking
 speeds up one-time build
--enable-silent-rules less verbose build output (undo: "make V=1")
--disable-silent-rules verbose build output (undo: "make V=0")
--enable-maintainer-mode
enable make rules and dependencies not useful
(and
sometimes confusing) to the casual installer
--enable-assume-broken-pkgdb
Compile with support for broken package
databases
that may contain non-normalized paths with
multiple
slashes. This doubles time necessary to load
file
database. To see if you need to enable this
option,
check paths in your package database with 'grep
//
/var/log/packages/*' command.
--enable-static-spkg Create static spkg executable. Use
--enable-static-spkg=only for creating only
static
spkg binary that will be used by default.
..

Láthatjuk, hogy elég sok minden beállítható a program fordítása során. Amit én alapértelmezett be
szoktam állítani, a prefix, libdir, sysconfdir, localstatedir. A programokat mindig a /usr alá telepítem,
így a rendszer részét fogják képezni. Ugyanígy dolgoznak a slapt-src szkriptek is. Szinte soha nem a
/usr/local alá telepítenek semmilyen programot. Statikus libeket a legritkább esetben használok,
mert ha több program is fogja használni, akkor egy frissítés során elég egyszer újrafordítani a libet
tartalmazó forrást és a programok amik függenek tőle már az új és frissített libeket fogják használni.
Ha statikusan fordítjuk egyes programokhoz a libeket akkor minden egyes frissítés után magát a
programokat is újra kellene fordítanunk. Ugyanígy ha a debug kikapcsolható akkor azt is
megteszem. Erre leginkább csak akkor van szükség ha a későbbiek folyamán valamilyen program
hiba esetén próbáljuk meg kideríteni, hogy hol lehet a probléma.

./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc

--localstatedir=/var --enable-static=no

Ezzel már alapértelmezetten el tudunk indulni. Természetesen ez még mindig csak a felszín,
rengeteg egyéb beállításra van lehetőségünk. Például az mpd fordítása során nagyon sok kodek
támogatás ki/bekapcsolható.

A make parancsot kivételes esetektől eltekintve érdemes úgy indítani, hogy akár több szálon is
tudjunk fordítani, mert így lerövidíthető a fordítási idő. Ehhez a make után írt -j{1-65} kapcsolót
tudjuk használni. Néhány program felhívja a figyelmet, hogy nincs felkészítve többszálú fordításra.
Ha a program fordítása probléma nélkül végzett jöhet a telepítés.

make install

Ez minden a programhoz tartozó binárist, adatfájlokat és a program egyéb dolgait feltelepíti a

fájlrendszerbe. Most már indíthatjuk a programunkat. Ez így nagyon jó. A program lefordult,
feltelepedett és már használható is. Azonban mi van akkor ha úgy döntünk, hogy a továbbiakban
nincs rá szükségünk vagy egy sokkal újabb verziót szeretnénk telepíteni? Távolítsuk el a régi
programunkat. Ha a forrásunk még rendelkezésre áll és a configure szkript tartalmazza az
eltávolításhoz szükséges információkat akkor egy

make uninstall

parancs kiadása után eltávolíthatjuk a régi programot. Ezzel azonban van egy kis probléma. A
forrást állandóan gépen kell tartani. Nem biztos, hogy a program forrása támogatja az uninstall
opciót. Kis apró programoknál ez még nem is jelent akkora problémát, de egy webkitgtk, kernel,
libreoffice forrás elég nagy szeletet hasít ki a "szűkös" tárterületből.

Nézzük milyen lehetőségeink vannak, hogy megoldjuk ezt a problémát:

1. porg (paco) használata

2. make DESTDIR és Slackware csomagkészítés
3. slkbuild vagy egyéb Slackbuild szkript használata

Vágjunk bele!

1. porg (paco) használata

A kedvencem! A programot a http://porg.sf.net oldalról tudjuk letölteni. Fordítsuk le, telepítsük fel.

./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc

--disable-grop
make -j5
make install-strip

A /etc/porgrc fájlban eszközöljünk egy apró változtatást. Mivel én általában a /home/build alatt
tartom a forrásokat és itt is végzem el a fordítást ezért az EXCLUDE sort kiegészítem a :/home
résszel. Így az itt keletkező fájlokat nem fogja a porg a csomag részének tekinteni és a telepített
fájlok között nem jelennek meg ezek a fájlok amik itt keletkeznek.

A porg használata nagyon egyszerű. A neve is utal a funkciójára: Package ORGanizer. A porg a
make install futtatását bővíti ki, tehát egy program fordítása ezentúl az alábbiak szerint fog kinézni:

./confgure --paraméterek
make -j5
porg -lp programneve "make install"

A porgnak a két paramétere az alábbiakat jelenti, -l mint log mód, tehát a make install közben a
keletkező fájlokat fogja átvezetni a saját adatbázisába, a -p programneve pedig meghatározza, hogy
mi legyen a program neve ami az adatbázisban tárolódik és ehhez fognak a fájlok kapcsolódni. A
porg a saját adatbázisát a /var/log/porg alatt tárolja. A telepített programokat a porg -ia paranccsal
tudjuk kilistázni. Egy-egy programot a porg -i programneve segítségével tudunk megnézni:

#porg -i galculator
------------
galculator
------------
Name: galculator
Version:
Summary: GTK 2 based scientific calculator
Author: Victor Soroka
License: GPL
URL:
Description:
galculator is a GTK 2 / GTK 3 based scientific calculator with
"ordinary" and reverse polish notation.

A csomaghoz tartozó telepített fájlokat pedig a porg -f programneve utasítással kérdezheted le:

# porg -f galculator
galculator:
/usr/bin/galculator
/usr/man/man1/galculator.1
/usr/share/applications/galculator.desktop
/usr/share/galculator/ui/about.ui
/usr/share/galculator/ui/basic_buttons_gtk2.ui
/usr/share/galculator/ui/basic_buttons_gtk3.ui
/usr/share/galculator/ui/classic_view.ui
/usr/share/galculator/ui/dispctrl_bottom_gtk2.ui
/usr/share/galculator/ui/dispctrl_bottom_gtk3.ui
/usr/share/galculator/ui/dispctrl_right_gtk2.ui
/usr/share/galculator/ui/dispctrl_right_gtk3.ui
/usr/share/galculator/ui/dispctrl_right_vertical_gtk2.ui
/usr/share/galculator/ui/dispctrl_right_vertical_gtk3.ui
/usr/share/galculator/ui/main_frame.ui
/usr/share/galculator/ui/main_frame_hildon.ui
/usr/share/galculator/ui/paper_view.ui
/usr/share/galculator/ui/prefs-ume.ui
/usr/share/galculator/ui/prefs_gtk2.ui
/usr/share/galculator/ui/prefs_gtk3.ui
/usr/share/galculator/ui/scientific_buttons_gtk2.ui
/usr/share/galculator/ui/scientific_buttons_gtk3.ui
/usr/share/icons/hicolor/48x48/apps/galculator.png
/usr/share/icons/hicolor/scalable/apps/galculator.svg
/usr/share/locale/da_DK/LC_MESSAGES/galculator.mo
/usr/share/locale/de/LC_MESSAGES/galculator.mo
/usr/share/locale/es/LC_MESSAGES/galculator.mo
/usr/share/locale/es_MX/LC_MESSAGES/galculator.mo
/usr/share/locale/fr/LC_MESSAGES/galculator.mo
/usr/share/locale/hu/LC_MESSAGES/galculator.mo
/usr/share/locale/ja/LC_MESSAGES/galculator.mo
/usr/share/locale/kk_KZ/LC_MESSAGES/galculator.mo
/usr/share/locale/lt/LC_MESSAGES/galculator.mo
/usr/share/locale/pl/LC_MESSAGES/galculator.mo
/usr/share/locale/pt/LC_MESSAGES/galculator.mo
/usr/share/locale/pt_BR/LC_MESSAGES/galculator.mo
/usr/share/locale/ro/LC_MESSAGES/galculator.mo
/usr/share/locale/ru/LC_MESSAGES/galculator.mo
/usr/share/locale/sk/LC_MESSAGES/galculator.mo
/usr/share/locale/sv/LC_MESSAGES/galculator.mo
/usr/share/locale/tr/LC_MESSAGES/galculator.mo
/usr/share/locale/zh_CN/LC_MESSAGES/galculator.mo
/usr/share/locale/zh_TW/LC_MESSAGES/galculator.mo
/usr/share/pixmaps/galculator.xpm

Eltávolítás egyszerűen porg -r programneve. Ezenkívül rengeteg egyéb opciója is van a

programnak. Érdemes a man oldalát olvasgatni.

Fontos megjegyezni, hogy az így kezelt programok nem tekinthetők teljes értékű Slackware
csomagnak, egyszerűen csak a forrásból fordított programok könnyű kezelhetőségét teszi lehetővé.
A man oldalakat (általában) nem tömöríti, a binárisok nem stripped állapotúak (make install-strip
nélkül, nem minden program használja). Ennek ellenére nagyon szeretem, gyors, egyszerű és
könnyen karbantartható. Az így készített csomagokból bármikor lehet könnyedén Slackware
csomagokat is készíteni. Én nem nagyon szoktam. Nekem jó ez így.

2. make DESTDIR és Slackware csomagkészítés

Használjuk telepítéskor a DESTDIR változót! Nem minden program forrása ismeri, de

általánosságban a legtöbb igen. Adjunk meg egy könyvtárat ahová telepíteni szeretnénk a
programot:

./configure --paraméterek
make -j5
make install DESTDIR=/home/csomagok/programneve

Az így telepített program nem a rendszerbe kerül hanem a DESTDIR által meghatározott
könyvtárba. Természetesen ugyanolyan szerkezetben mint ahogy az majd rendes telepítés után a
fájlrendszerben is látszani fog. Lépjünk be a könyvtárba, hozzunk létre egy install/ könyvtárat azon
belül töltsük ki a slack-desc fájlt. Tömörítsük a binárisokat a strip programmal ha szükséges, a man
oldalakat pedig gzip formátumra. Ezután elkészíthetjük a Slackware csomagot a már megismert
makepkg segítségével:

makepkg ../programneve-verziószám-arch-build.txz

Ez kézi munka. Egy-két programnál elfogadható, de tömeges fordításnál elég időigényes. Ez miatt
ezt csak ritkán használom, általában egyedi .deb fájlok kibontása és átcsomagolásakor.

3. slkbuild vagy egyéb SlackBuild szkript használata

A valódi csomagkészítés. Használjuk a slkbuild programot http://slkbuild.sourceforge.net/ (Arch

rendszerken ismerős lehet pkgbuild néven), vagy egyszerűen írjuk meg a saját
programneve.SlackBuild szkriptünket. Ezt a legkönnyebben úgy tudjuk megtanulni ha elemezzük
más programok szkriptjeit. Nem nehéz a saját szkriptek megírása, de azért odafigyelést igényel,
hogy ne rontsunk el semmit. Lehet 3-4 próbálkozásra fog sikerülni, de ha simán forrásból fel tudunk
telepíteni egy programot akkor SlackBuild szkriptet írni hozzá nem okozhat nehézséget.

Utóírat

Nagyon sok mindent nem érintettem a leírásban, így gépelés közben jutott eszembe, hogy mi van
akkor ha a program könyvtárában nincs configure szkript csak autogen.sh. Ekkor sem kell kétségbe
esni, futtassuk ezt a configure előtt és utána ha minden hibátlanul lefutott már mehet a fordítás.
Újabban nagyon sok program használja a cmake rendszert, van amik a waf-ot részesítik előnyben.
Az ilyen programokat is simán tudjuk fordítani, csak itt kicsit másképpen néznek ki a
paraméterezések. Egyes, főként régebbi programoknál előfordul, hogy következesen elszállnak
hibával a fordítások. Sok ilyen program már elhagyott állapotban van és nincs felkészítve az újabb
rendszerekhez való fordításra. Nincs gond. A Debian, Ubuntu, Arch és más disztribúció készítői
elég sok patch-et készítenek a régebbi és még használt programokhoz. Ezeket töltsük le bátran és
használjuk a forrásból kibontott állományokon. Az így kijavított forrás általában már le fog fordulni
és tökéletesen működő programot kapunk.

Hirtelen ennyi jutott eszembe amit le tudtam írni. Ha kérdések lennének akkor megpróbálok
válaszolni.

Mindenkinek jó csomagolást :)