Építsünk saját GNU/Linux rendszert! (újraélesztés!)

Tavaly ilyenkor kezdtem el nagy sikerű Építsünk saját GNU/Linux rendszert! blogsorozatomat (#1, #2, #3, valamint lazán kötődik a csomagkezelésről általában írt összefogalóm). Ha átnézitek a belinkelt részeket, láthatjátok, hogy írtam a célkitűzésről, ledokumentáltam az ideiglenes /tools rendszer építését, és leírtam, hogy hogyan lesz majd pacmannel a csomagkezelés a végleges alaprendszerben. Viszont arról már nem esik szó, hogy elkezdem építeni magát a rendszert. Valójában addig jutottam el, hogy felépítettem az alaprendszer csomagkezeléssel, be is lehet bootolni, és utána azzal küzdöttem, hogy valami upstart alapú párhuzamosított rendszerindítást faragjak, de ez kemény fának bizonyult.

Rögtön itt az elején közlöm a tanulságokat:

  1. Haladjunk apró lépésekben, és ne akarjunk mindent egyszerre!
  2. Dokumentálni egyáltalán nem élvezetes, viszont hosszú távon mindenképpen kifizetődő.

Ezeknek megfelelően az újraélesztett Építsünk saját GNU/Linux rendszert! projektemben a következő változtatásokat eszközlöm:

  1. Az LFS/BLFS könyvekhez képest mindössze két célkitűzésem lesz pluszban: karbantarthatóság és rend. A karbantarthatóságot elsősorban a csomagkezelés által igyekszem elérni. A rend alatt pedig azt értem, hogy a csomagok tartalma olyan szép legyen, mint egy Debianban; erről néhány konkrétabb dolgot olvashattok az első rész végén a kibővített célkitűzéseknél. Egyelőre lemondok arról, hogy átszabjam a rendszerindítást. Szintén nem fogok foglalkozni mai sokmagos és sokbites processzorok világában egyre aktuálisabb témákkal, hanem egy régi 32 bites egymagos processzoron építek egy 32 bites rendszert. Ezekre majd később visszatérhetek, amikor már van egy működő, korrekt csomagkezeléssel rendelkező rendszerem.
  2. Tavaly a késleltett dokumentálással az volt a célom, hogy csak letisztázott lépéseket tegyek közzé. Most igyekszem folyamatosan írni, ahogy haladok, így valószínűleg látni fogjátok azokat a lépéseimet is, ahonnan aztán visszalépek, hogy mást csináljam. Így talán nehezebben lesz követhető, de úgy vélem cseppet sem lesz kevésbé tanulságos.

Az elmúlt évben számos dolog változott, ezért most alapoktól újra fogom építeni a rendszert.

  • Megjelent az LFS könyv 6.5-ös változata. Benne a GNU DBM váltotta fel a Berkeley DB-t, valamint jelenleg a fejlesztő változatban már GRUB 2 található a GRUB Legacy helyett. Talán vannak más jelentősebb változások is, de eddig nekem még csak ennyi tűnt fel.
  • Megjelent az xz-utils az lzma-utils leváltására. Ez ugyanúgy LZMA tömörítést használ, csak sokkal normálisabb fájlformátummal. Ma már a Slackware is ezt használja. Így valószínűleg megszűnt az az érdekes probléma, amit a második részben a A bsdtar és az lzma kitömörítés rövid története rész alatt írtam le.
  • A pacman háza táján is fejlődés történt. Nevezetesen számomra két fontos fejlemény történt: egy PKGBUILD-ből több csomag készítésének támogatása, valamint az info fájlok kezelése fejlődött. Bár az még meg kell vizsgálnom, hogy az info fájlok kezelése most tökéletes-e.
  • Az elmúlt évben megismerkedtem a verziókezeléssel. Elsősorban Bazaart tanulgattam, de úgy érzem, ezután már más verziókezelőkkel is könnyebben boldogulok. Tervezem, hogy git-et használok majd a /tools és az alaprendszer backupolására. Mivel relatíve nagy mennyiségű adatról van szó, ezért fontos a git gyorsasága, továbbá ez esetben nem számít, hogy a git Linux-only. PKGBUILD fájlokat pedig valószínűleg Bazaarral fogom kezelni. Ha nagyon olyan kedvem lesz, RCS-sel mentegethetem az /etc-t. De ez most inkább csak ötletelés, majd még kitalálom pontosan mi lesz.
  • A DIY Linux projekt úgy tűnik meghalt. Áprilisban volt az utolsó módosítás a Reference Builden. Kár érte, pedig igen hasznos információk vannak benne, és ha nem frissítik, akkor azok elavulnak és használhatatlanná válnak. A BLFS tavaly is olyan mostohán állt, mint most.
  • Az elmúlt évben az alaprendszer legtöbb alkatrészének jelent meg újabb verziója, amik új funkciókat is hozhattak magukkal.

Lássuk tehát az ez alkalommal tervezett sajátosságokat részben a módosítatlan LFS-hez, részben az előzőleg tervezett sajátosságokhoz viszonyítva:

  • Nem lesz dash, metalog, syslog-ng, rsyslog vagy upstart. Marad a könyv szerint a bash, sysklogd és sysvinit.
  • Marad a vim az alapértelmezett editor, de az Arch Linuxból utánzott módon elkészítve, hogy szépen színezze a PKGBUILD fájlokat.
  • GNU tar helyett bsdtar/libarchive lesz ismét. Amúgy is kell a pacman miatt.
  • Az adott számítógép hardverét figyelembe véve OSS v4.x lesz ALSA helyett. (Ember legyen a talpán, aki ezt korrektül tudja csomagolni.)

Hogy ez a bejegyzés teljes legyen, és tartalmazza az új célkitűzéseket a régiekkel együtt, kiegészítve vagy javítva átveszek bizonyos részeket az eredeti első részből. Az egy az egyben átvett részeket a könnyebb olvashatóságért sötét kékkel írtam.

Tervezett csomagkezelés

  1. Az alaprendszer csomagjait az Arch Linuxból idecsempészett pacman-nel fogom kezelni. (Ez nem lesz szerintem túl nehéz, csak időigényes, mert minden csomag csomagolásával külön kell majd szöszölni. Viszont cserébe a későbbi eltávolítások/frissítések zökkenőmentesebbek lesznek, mintha egyáltalán nem használnék csomagkezelőt.) Az előző kisérletben rengeteg csomagot becsomagoltam, és megvannak még a régi PKGBUILD-ek, szóval ez nem lesz olyan vészes.
  2. Jelenlegi terv szerint a további felhasználó programokat pkgsrc-vel próbálom majd meg rávarázsolni a rendszerre. (Mert a BLFS sokkal időigényesebb, mint az LFS. Kíváncsi vagyok, hogy a saját GNU/Linuxon hogy muzsikál majd a pkgsrc.) Itt még lehet, hogy érnek majd meglepetések, mivel még nem próbáltam pkgsrc-t LFS-re hegeszteni.

Rendszerezettségre vonatkozó követelmények

  • A rendszernek akkor is teljes mértékben korrektül kell működnie, ha a 

/boot

, 

/home

, 

/var

, 

/tmp

, 

/usr

, 

/usr/local

külön partíción foglalnak helyet. Ennek érdekében a gyökérpartíción kell lennie minden olyan binárisnak és egyébnek, amely a bootolás korai szakaszában (a többi fájlrendszer felmountolása előtti szakaszában) szükséges. Amennyiben a valamelyik partíció mountolása nem sikerül, a gyökérpartíción ott kell, hogy legyenek azok az eszközök, amelyekkel az alapvető javítások elvégezhetők.

  • Ugyanakkor semmi értelme annak, hogy egy bináris a
    /bin

    -ben vagy 

    /sbin

    -ben legyen, ha olyan shared library-k kellenek a működéséhez, melyek a 

    /usr

    -ben találhatók. Ezért minden 

    /bin

    -ben ill. 

    /sbin

    -ben található bináris működéséhez szükséges shared librarynek a 

    /lib

    -ben a helye.

  • Ugyanakkor a statikus könyvtáraknak (
    *.a

    ) és libtool fájloknak (

    *.la

    ) semmi keresnivalójuk a 

    /lib

    -ben; nekik a fejállományokkal együtt (

    *.h

    ) a 

    /usr

    -ben a helyük, mivel csak fordításkor van szükség rájuk.

  • Az alaprendszer nem pakolhat semmit a
    /usr/local

    -ba

    , kivéve az alapvető könyvtárstruktúrát és linkeket.
  • A rendszernek akkor is tökéletesen működnie kell, ha a
    /usr

    csak olvasható

    an van mountolva. Használat közben változó adatoknak a 
    /var

    -ban, konfigurációs fájloknak a 

    /etc

    -ben a helye. A 

    /usr

    -nek csak akkor szabad/kell változnia, ha a csomagtelepítés, -eltávolítás ill. frissítés történik. Ahol csak észreveszek developerek által helytelenül beállított programokat, igyekszem ilyen működésre kényszeríteni.

  • Minden csomag tartalma legalább ránézésre ;) rendezett és áttekinthető legyen.

    • Ha minden a terv szerint halad, akkor hamarosan jelentkezem a /tools építésével. :)

    ( LGee | 2010. 01. 11., h – 10:26 )

    Nincs kedved betenni az egeszet a HUP wikibe? (Ha a kerdes mar korabban is felmerult, akkor bocs.)

    Hmm... A legtöbb rész inkább tekinthető az én egyedi rendszerépítésem történetének, mintsem univerzális leírásnak, így blogba szerintem jobban illik. Másrészt, nincs hozzáférésem a HUP wikihez. Viszont lehet, hogy wikiben kényelmesebb lenne szerkeszteni, és külalakra jobban nézne ki a cikk.

    ( utpKabel | 2010. 01. 11., h – 13:30 )

    Egy kis előzetes.

    Megválasztottam a GLibC, GCC, Binutils, Linux kernel verziókat.

    Binutils 2.20
    GCC 4.3 20100110
    EGLibC 2.10 SVN
    Linux 2.6.27.x

    GCC-ből úgy döntöttem nem választom a legújabb stabil ágat, hanem az eggyel régebbit. Gondolkodtam, mi a rosszabb: ismert hibák, vagy teszteletlen hibajavítások? Végül aztán vettem a 4.3 ág legújabb .tar.bz2-ben csomagolt snapshotját, mondhatnám úgy is, hogy 4.3.5 prerelease. Nem biztos, hogy jó döntés volt, de hát azért van a testsuite, hogy ezt segítsen eldönteni.

    LibC-nek SVN-ből letöltöttem az EGLibC 2.10-es ágát, ami 2.10.2-nek hívja magát. Elvileg forrás és binárisan kompatibilis a GLibC-vel, Debiannak jó, Ubuntunak jó, amúgy sem akartam a legújabbat rakni, talán nekem is jó lesz. Majd a testsuite során kiderül. :)

    Kernelből pedig a 2.6.27-es ágat választottam, mivel ez hosszú karbantartású, az adott gépen pedig már nagyon régóta minden hardver támogatott.

    ( gtomy | 2010. 01. 25., h – 16:25 )

    Engem is nagyon foglalkoztat a téma. Azért is, mert valami ilyesmiből
    szeretnék diplomamunkát írni. Mondjuk még nem rágtam át magam az LFS
    könyvön. Tehát nincs akkora rálátásom és tapasztalatom a dologban
    mint neked. Szerinted 64bites rendszert is "könnyen" meg lehet építeni?