Home Wiki > Build Service
Sign up | Login

Build Service

tagline: A openSUSE wikiből

Icon-marcom.png Az alábbiakban bemutatjuk az openSUSE összeállító szolgáltatását (Build Service). Szemben más rendszerekkel, ez nem egy adott disztribúcióra koncentrál, hanem többet is képes kiszolgálni. Úgy készült, hogy egyszerűen lehessen elágaztatni egy csomagot például módosítások kipróbálásához vagy eltérő csomagkonfiguráció használatához. A rendszer automatikusan újraépíti a csomagokat, ha azt észleli, hogy a tartalmuk megváltozott.

Bevezető

A nyílt forráskód fontos előnyei a rendelkezésre álló szoftverek nagy száma és a gyors frissítési ciklusok. Ennek az előnynek azonban ára van: a szoftverek szerzőinek garantálniuk kell, hogy a programjuk futni fog a legfrissebb rendszereken. A felhasználók pedig elvárják a bináris változatokat, bár a fordítás sokáig tart és sokszor nehézkes. Minden bináris változat állandóan naprakészen tartása azonban roppantul időigényes. Néha kifejezetten lehetetlen, ha a szoftver szerzője nem fér hozzá egy kívánt architektúrához vagy disztribúcióhoz. A SourceForge-hoz hasonló projektgyűjtő szerverek hozzáférést biztosítanak egy különböző architektúrákat használó gépekből álló „fordítási farmhoz”, különböző verziójú disztribúciókkal. A csomagok összeállítása azonban továbbra is kézi folyamat, vagyis egy új összeállítást továbbra is kézzel kell elkészíteni, ha a disztribúció megváltozik. Más rendszerek csak egy adott disztribúcióhoz képesek előállítani a csomagokat, vagy pedig kézi közreműködésre van szükség az összeállítások újra elvégzéséhez. Az openSUSE összeállító szolgáltatása úgy készült, hogy a szoftverek szerzőinek kényelmes eszközt nyújtson csomagjaik többféle disztribúcióhoz való előállításához, illetve lehetővé tegyék az automatikus újrafordítást, ha a disztribúció megváltozik. Legfontosabb jellemzői:

  • nem koncentrál egyetlen disztribúcióra;
  • egyszerűen kezelhetőek a csomagok különböző verziói;
  • automatikusan végrehajtható az újrafordítás.

Minden szoftverkészítő szabadon felhasználhatja az összeállító szolgáltatást, hogy elkészítse szoftverének csomagjait különféle disztribúciókhoz és azokat automatikusan naprakészen tarthassa. Akik szeretnek kísérletezni, készíthetnek egyéni csomagváltozatokat. Akik egy adott csomagot keresnek, végignézhetik az összeállító kiszolgálón, hogy van-e az igényeiknek megfelelő változat. Az alábbi dokumentumban az openSUSE összeállító szolgáltatásának felépítését írjuk le. Megjegyeznénk, hogy az anyag egyelőre még csak vázlat, nem minden elv van teljesen kidolgozva és egyes dolgok megváltozhatnak a végső verzióban.

Projektek

A projekt az openSUSE összeállító szolgáltatás alapvető építőkockája. A projektek forrásfájlokat tartalmazó csomagokból állnak, és ezek a forrásfájlok szolgálnak az egyes csomagok bináris RPM-jeinek az előállításához.

Hozzáférés-vezérlés

Egy projekt létrehozásakor a létrehozó automatikusan a projekt adminisztrátorává válik. Az adminisztrátor felvehet és eltávolíthat csomagforrásokat és módosíthatja a projekt konfigurációját. A konfigurációnak szintén része az adminisztrátorok listája, vagyis egy adminisztrátor felvehet más felhasználókat az adminisztrátorok listájába.

A projekt rétegei

Build Service 1.gif
Build Service 2.gif

Az összeállítási folyamatnak el kell készítenie egy összeállítási rendszert, amelyben az összes rpm telepítve van. Mivel az egyes projektek csak a bennük található csomagok RPM-jeit tartalmazzák, megadható egy olyan projekt, amelyik más projektek felett helyezkedik el (rájuk épül). Egyszerű példaként vegyük a KDE4 projektet, amelyik a következő KDE-kiadás csomagjait tartalmazza. A csomagok összeállításához más RPM-ekre (például fordítóprogramokra és egyéb eszközökre) is szükség van. Vagyis a KDE4 csomagot egy másik olyan projekt tetejére kell elhelyezni, amelyik már tartalmazza ezeket az RPM-eket – ilyen például az openSUSE Factory disztribúció. Vegyünk egy másik projektet: a KVIM egy csomagban a kvim programot, a népszerű szerkesztő grafikus változatát tartalmazza. A KVIM rendszergazdák nyilván biztosítani kívánják csomagjukat KDE4-hez, tehát ők a KDE4 csomag fölé helyezik el a projektjüket. Nem kell megadniuk, hogy a KVIM-nek a Factory csomagokra is szüksége van, ugyanis ez a rétegzés automatikusan öröklődik. A KVIM csomag összeállításakor a rendszer be lesz állítva a KDE4 projekt kde csomagjaival és a Factory projekt alapcsomagjaival.

A szükséges csomagok megadása

A SUSE Linuxban található „build” program használói nyilván tudják, hogy jelenleg egy csomag által igényelt RPM-ek megadása úgy történik, hogy az összeset be kell írni „BuildRequires” sorokba. Mivel ez nem túlságosan rugalmas megoldás, az openSUSE összeállító szolgáltatása az egyes RPM-ek requires listájával, tranzitív módon, automatikusan kibővíti a BuildRequires feltételeket. Ennek eredménye­képpen drasztikusan csökken a megadandó RPM-ek száma. Normális esetben csak néhány „-devel” csomagot kell megadni, például a cups csomaghoz elegendő megadni BuildRequires feltételként, hogy „gcc-c++ libpng-devel libtiff-devel openslp-devel openssl-devel pam-devel tcpd-devel”. Ez a csökkentés megnöveli annak valószínűségét is, hogy csomag változtatások nélkül, problémamentesen lefordul más disztribúciókon is. A BuildRequires következtében a neededforbuild el fog avulni.

Rétegek és megbízhatóság

Fontos tudni, hogy melyik projektek szolgáltak egy csomag összeállítására, hiszen a projektek csomagjai olyan rosszindulatú kódot is tartalmazhatnak, amely tönkreteheti az összeállítás eredményét. Alapszabály, hogy egy projekt csomagjai nem lehetnek megbízhatóbbak az összeállításhoz használt projekteknél.

Összeállítás többféle architektúrához

Egy projekt megadhatja, hogy a csomagjai többféle architektúrákhoz is elkészüljenek. Ki is hagyhatók bizonyos architektúrák a csomagokból, hogy a reménytelen összeállításokkal meg se lehessen próbálkozni. Ne feledjük, hogy a rétegzés korlátozza a használható architektúrák számát: ha a rétegek bármelyike nem támogat egy adott architektúrát, akkor lehetetlen lesz RPM-et készíteni ahhoz az architektúrához, hiszen az összeállítási rendszer kialakításához szükséges csomagok nem állnak rendelkezésre.

Összeállítás többféle disztribúcióhoz

Build Service 3.gif

Az openSUSE összeállító szolgáltatás fontos funkciója, hogy nemcsak többféle architektúrához, hanem többféle disztribúcióhoz is tud készíteni csomagokat. Lehet szó akár a SUSE Linux vagy a SLES régebbi változatairól, de akár idegen disztribúciókról is, mint a Fedora vagy a Mandriva. Többféle disztribúcióhoz történő összeállítás során minden egyes disztribúcióhoz ki kell alakítani a megfelelő összeállítási környezetet. A projekt tulajdonságai – mint például a rétegzés vagy az architektúrák – ténylegesen az összeállítási környezet tulajdonságai. Egy másik környezetnek más jellemzői lehetnek.

Vegyük ismét példának a KDE4 projektet. Jelenleg a Factory projektre épít az i586 és ppc architektúrák esetén. A fenntartók úgy döntöttek, hogy a Mandrivához is készítenek csomagokat. Éppen ezért fel kell venniük egy új összeállítási környezetet, amely a Mandriva disztribúció tetejére épül. A példánkban a Mandriva csak i586 RPM-eket tartalmaz az openSUSE összeállító szolgáltatásban, vagyis csak i586 KDE4 RPM-ek készíthetők hozzá.

Csomagforrások

Egy csomag forrásának három fajtája van: egy teljes forrás, egy hivatkozás egy másik projekt csomagjára, valamint egy hivatkozás egy javítókészletre.

Teljes forrás

Ez a forrás legegyszerűbb formája: a csomag előállításához szükséges néhány fájl.

Forráshivatkozások

Build Service 4.gif

Néha hasznos lehet létrehozni egy pontos másolat helyett egy hivatkozást egy másik projekt csomagjára. A hivatkozás előnye, hogy a forrás változásai automatikusan átvezetődnek. Vegyük ismét példának a KDE4 projektet. Tegyük fel, hogy a rendszergazdák egy olyan amarok csomagot szeretnének, amelyikben már az új KDE4 függvénytárak találhatók. Ehhez létrehoznak egy hivatkozást az openSUSE Factory projekt amarok csomagjából. Ha az amarok csomag módosul a Factory projektben, akkor automatikusan elkészül egy frissített KDE4-verzió.

Forráshivatkozások javításokkal

Gyakran csak egy kis részletet kell módosítani a forrásban, például egy konfigurációs paramétert. Ebben az esetben a hivatkozás egy sor javításra a preferált megoldás. Ez úgy viselkedik, mint egy normál forráshivatkozás, de a csomag összeállítása előtt a javítások automatikusan alkalmazásra kerülnek. A normál hivatkozáshoz hasonlóan a csomag változásai átvezetődnek, vagyis a forrás módosításának hatására új összeállítás készül. Ismét csak egy példa: tegyük fel, hogy a KDE4-es fiúk szeretnének egy „könnyített” amarok csomagot kapcsolni a KDE4 függvénytárakhoz. Ehhez létrehoznak egy új, LW AMAROK nevű projektet, ráhelyezik a KDE4-re és létrehoznak egy hivatkozást az amarok csomag egy javítására.

Csomagok átadása más projekteknek

Build Service 5.gif

Tegyük fel, hogy a KDE4 projekt óriási siker lett és minden problémamentesen működik. Most a projekt karbantartói azt szeretnék, hogy a Factory disztribúció vegye fel az ő forrásukat. Ehhez egy áthelyezési kérést nyújtanak be a Factory projekthez. A Factory karbantartói kilistázzák az összes nyitott kérést és készítenek egy különbséglistát a benyújtott csomagok és a disztribúciójukban található csomagok között. Ha úgy gondolják, hogy a csomagok megfelelnek a befoglalási irányelveknek, akkor átmásolják a forrásfájlokat a saját projektjükbe.

Áttekintők

A csomagok forrásait csak a projekt adminisztrátorai módosíthatják: ők felelősek azért, hogy ellenőrizzék a különbségeket a források között és eldöntsék, hogy a benyújtott csomag elfogadható-e vagy sem. Mivel ez meglehetősen sok munka nagy projektek esetén, megadhatók áttekintők (reviewers) a projekt bármely csomagjához. Ha egy másolási kérés érkezik egy olyan csomagra vonatkozóan, amelyhez van kijelölve áttekintő, akkor a kérés először az áttekintőhöz kerül. Az áttekintő megvizsgálja a forráskód változásait és megjegyzéseket fűz hozzá. Ha az áttekintő javasolja az átmásolást, akkor ő újraküldi a kérést a projekt adminisztrátorainak, akik most már az ő megjegyzései alapján dönthetnek.

Csomagok összeállítása

Miután a csomag létre lett hozva egy projektben, automatikusan összeállításra kerül az openSUSE összeállítási farmon.

Elszigetelés (sandboxing)

Mivel egy felhasználó szabadon felhasználhatja az összeállító szolgáltatást bármilyen forrásfájlokhoz, vigyázni kell a rosszindulatú kódokkal. Ez nem annyira a tényleges összeállítás problémája (ami ugye nem root felhasználóként történik), hanem az összeállítási rendszert alkotó RPM-ek telepítéséé, hiszen ez a művelet a root felhasználó nevében zajlik. A folyamat biztonságossá tételéhez a Xen segítségével egy virtuális gépet készítettünk az összeállításhoz. További előnyként a rosszindulatú folyamatok nem férnek hozzá a hálózathoz és az összes folyamat automatikusan leállításra kerül az összeállítás után.

Automatikus újraépítések

Az openSUSE összeállító szolgáltatás automatikusan újraépíti a csomagokat, ha azok lejártak. Egy csomag lejárt, ha

  • a forrása módosult
  • hivatkozás esetén a hivatkozott forrás módosult,
  • javításos hivatkozás esetén a javított forrás vagy a javítások egyike módosult,
  • a csomag összeállításához használt RPM-ek valamelyike lejárt és újra lett építve.

Ne feledjük, hogy a lejáratot figyelő algoritmus csak a forráskódok változását nézi, vagyis nem indul el egy végtelen összeépítési ciklus egy függőségi kör megléte esetén.

Kiadási számok

Az openSUSE összeállító szolgáltatás automatikusan kiadási számokat rendel az összeállított csomagokhoz. A kiadási szám két részből áll: az első a forrás módosításszámlálója, amelyet egy újraépítési számláló követ. Minden egyes alkalommal, amikor a csomag forrása módosul, a forrásváltozás-számláló megnő, és az újraépítés-számláló visszaáll 1-re. Ha tehát a régi kiadásszám „4.5” volt és a forrás módosul, akkor a következő összeállítás kiadása „5.1” lesz, a következő újraépítésé (ha a forrás nem változott) „5.2” és így tovább. A kiadásszámozás egy projekten belül helyinek számít. Ez azt jelenti, hogy két projekt kiadásszámainak összehasonlítása értelmetlen. A nagyobb kiadásszám nem feltétlenül jelenti azt, hogy a csomag forrása újabb. Kivételt képeznek persze a hivatkozott/kapcsolt csomagok, ahol a hivatkozott kiadás száma mindig magasabb, mint a hivatkozás forrásáé. Hisszük, hogy két projekt csomagjainak összehasonlítása más szinten, irányelvek által meghatározandó kérdés, amit egyszerű számozási renddel nem lehet szabályozni. A csomagkarbantartó szoftvernek kell valamilyen eszközt nyújtania az adminisztrátor számára, hogy beállíthassa két projekt közötti rendezést. A projekt saját kiadásszámainak vagy korszakszámainak összehasonlítás nem jár értelmes eredménnyel. Még az a vélemény sem nélkülöz minden alapot, hogy a verziószámokat sem szabad összehasonlítani, bár a verziószám nem helyi, hiszen az „feljebb” kerül meghatározásra.

Összefoglalás

Az openSUSE összeállító szolgáltatás úgy készült, hogy lehetővé tegye a szoftverszerzők és csomagkészítők számára, hogy szoftvereik bináris csomagjai mindig naprakészek legyenek. Ehhez létre kell hozniuk egy, az összeállítandó csomagokat tartalmazó projektet, és ezt rá kell helyezniük egy vagy több disztribúcióra. Forráshivatkozások és javításos hivatkozások használhatók a csomagok változásainak egyszerű nyomon követéséhez. A rendszer automatikusan összeállítja (és újraépíti) a szoftvert, hogy a felhasználóknak mindig a legfrissebb verzió álljon a rendelkezésére. Az összeállítási folyamat a Xen hypervisor rendszert használja a különböző összeállítások elszigeteléséhez.