Illusztráció egy csomagkezelőről, amelyet új szoftverek letöltésére használnak. A manuális műveletek közé tartozhat a licencszerződés elfogadása vagy néhány csomagspecifikus konfigurációs opció kiválasztása.

A szoftvercsomag egy olyan archív fájl, amely egy számítógépes programot, valamint a telepítéséhez szükséges metaadatokat tartalmazza. A számítógépes program lehet forráskódban, amelyet először le kell fordítani és meg kell építeni. A csomag metaadatai közé tartozik a csomag leírása, a csomag verziója és a függőségek (más csomagok, amelyeket előzetesen telepíteni kell).

A csomagkezelők feladata a szoftvercsomagok megtalálása, telepítése, karbantartása vagy eltávolítása a felhasználó parancsára. A csomagkezelő rendszer tipikus funkciói a következők:

• A fájlarchiválókkal való együttműködés a csomagarchívumok kinyerése érdekében
• A csomagok integritásának és hitelességének biztosítása az ellenőrző összegek, illetve a digitális tanúsítványok ellenőrzésével
• A meglévő szoftverek keresése, letöltése, telepítése vagy frissítése egy szoftvertárból vagy alkalmazásboltból
• A csomagok funkció szerinti csoportosítása a felhasználói zavarok csökkentése érdekében
• A függőségek kezelése, hogy egy csomagot az összes szükséges csomaggal együtt telepítsenek, így elkerülhető a “függőségi pokol”

A megosztott könyvtárakkal kapcsolatos kihívásokSzerkesztés

A statikus könyvtárkapcsolás helyett dinamikus könyvtárkapcsolásra épülő számítógépes rendszerek a gépi utasítások futtatható könyvtárait megosztják a csomagok és alkalmazások között. Ezekben a rendszerekben a könyvtárak különböző verzióit igénylő különböző csomagok közötti összetett kapcsolatok a köznyelvben “függőségi pokolként” ismert kihívást eredményeznek. A Microsoft Windows rendszereken ezt “DLL-pokolnak” is nevezik, ha dinamikusan kapcsolt könyvtárakkal dolgozunk. A jó csomagkezelés létfontosságú ezeken a rendszereken. Az OPENSTEP Framework rendszere kísérletet tett ennek a problémának a megoldására azzal, hogy lehetővé tette a könyvtárak több verziójának egyidejű telepítését, és azt, hogy a szoftvercsomagok megadhassák, hogy melyik verzióhoz kapcsolódnak.

Front-endek a helyileg lefordított csomagokhozSzerkesztés

A rendszergazdák a csomagkezelő szoftvereken kívül más eszközökkel is telepíthetnek és karbantarthatnak szoftvereket. A helyi rendszergazda például letölthet csomagolatlan forráskódot, lefordíthatja és telepítheti azt. Ez azt okozhatja, hogy a helyi rendszer állapota nem lesz szinkronban a csomagkezelő adatbázisának állapotával. A helyi rendszergazdának további intézkedéseket kell tennie, például kézzel kell kezelnie egyes függőségeket, vagy a módosításokat integrálnia kell a csomagkezelőbe.

A helyben lefordított csomagok csomagkezelésbe való integrálásának biztosítására rendelkezésre állnak eszközök. A .deb és .rpm fájlokon alapuló disztribúciókhoz, valamint a Slackware Linuxhoz létezik a CheckInstall, a recept alapú rendszerekhez, például a Gentoo Linuxhoz és a hibrid rendszerekhez, például az Arch Linuxhoz pedig először receptet lehet írni, amely biztosítja, hogy a csomag illeszkedjen a helyi csomagadatbázisba.

A konfiguráció karbantartásaEdit

A szoftverfrissítéseknél különösen nagy gondot okoznak a konfigurációs fájlok frissítései. Mivel a csomagkezelők, legalábbis a Unix rendszereken, a fájlarchiváló segédprogramok kiterjesztéseként jöttek létre, általában csak a konfigurációs fájlokat tudják vagy felülírni, vagy megtartani, ahelyett, hogy szabályokat alkalmaznának rájuk. Ez alól vannak kivételek, amelyek általában a kernel konfigurációjára vonatkoznak (amely, ha elromlik, újraindítás után használhatatlanná teszi a számítógépet). Problémákat okozhat, ha a konfigurációs fájlok formátuma megváltozik; például ha a régi konfigurációs fájl nem tiltja le kifejezetten az új, letiltandó opciókat. Néhány csomagkezelő, például a Debian dpkg-ja lehetővé teszi a telepítés közbeni konfigurálást. Más helyzetekben kívánatos a csomagokat az alapértelmezett konfigurációval telepíteni, majd ezt a konfigurációt felülírni, például nagyszámú számítógépre történő fej nélküli telepítés esetén. Ezt a fajta előre konfigurált telepítést a dpkg is támogatja.

RepositoriesEdit

Azért, hogy a felhasználók jobban ellenőrizhessék, hogy milyen szoftvereket engednek telepíteni a rendszerükre (és néha a forgalmazók oldalán jogi vagy kényelmi okokból), a szoftvereket gyakran több szoftvertárból töltik le.

Frissítés elnyomásaSzerkesztés

Amikor a felhasználó kapcsolatba lép a csomagkezelő szoftverrel, hogy frissítést hajtson végre, szokás, hogy a felhasználó elé tárják a végrehajtandó műveletek listáját (általában a frissítendő csomagok listáját, és esetleg megadják a régi és az új verziószámot), és lehetővé teszik a felhasználó számára, hogy vagy tömegesen elfogadja a frissítést, vagy egyes csomagokat válasszon ki a frissítéshez. Sok csomagkezelő úgy konfigurálható, hogy bizonyos csomagokat soha ne frissítsen, vagy csak akkor frissítsen, ha a szoftver csomagolója által meghatározott kritikus sebezhetőségeket vagy instabilitást találnak a korábbi verzióban. Ezt a folyamatot néha verziószögezésnek nevezik.

Például:

• a yum támogatja ezt az exclude=openoffice* szintaxissal
• a pacman az IgnorePkg= openoffice-szal (az openoffice frissítésének elnyomása mindkét esetben)
• a dpkg és a dselect részben a hold flag segítségével támogatja ezt. a csomagválasztásban
• az APT kiterjeszti a hold flag-et a komplex “pinning” mechanizmuson keresztül (a felhasználók feketelistára is tehetnek egy csomagot)
• az aptitude rendelkezik “hold” és “forbid” flag-ekkel
• a portage támogatja ezt a csomagon keresztül.mask configuration file

Cascading package removalEdit

Néhány fejlettebb csomagkezelő funkció kínál “cascading package removal”-t, amelyben minden olyan csomagot, amely a célcsomagtól függ, és minden olyan csomagot, amelytől csak a célcsomag függ, szintén eltávolít.

Parancsok összehasonlításaEdit

Bár a parancsok minden egyes csomagkezelőre specifikusak, nagyrészt lefordíthatóak, mivel a legtöbb csomagkezelő hasonló funkciókat kínál.

Az Arch Linux Pacman/Rosetta wiki átfogó áttekintést nyújt.