Poslední dobou mám cukání se do LFS pustit, minimálně kvůli nové zkušenosti. Vypadá to zajímavě a díky těmhle článkům mám pocit, že bych to taky zvládnul.
Momentálně ale zkoumám jak modifikovat instalátor Debianu tak, abych si vytvořil automatickou instalaci (nabootuju z CD, stisknu Install a jdu na kafe).
LFS zvládneš jako cip. Já vim o programení hovno a taky jsem to zvládnul zkompilit a to si ani neumim v debianu pomalu nastavit sítovku. :-))) Ale doporučil bych jí spíše než cestou CLFS než LFS... CLFS tě učí cross kompilaci z jenoho na mnoha je tam zvládnuto 64 bitů...
yakuake je perfektni používám jej teprve krátce, ale už si nedokážu představit systém bez něj :) jinak pokud na to máte trochu času a zajímá vás to tak to určitě zkuste, to mimochodem bylo cílem těchto článků - popostrčit váhavce a ukázat jim že to není nic tak složitého, jenom to chce dostatek toho času (minimálně v začátku) :)
Osobne ma LFS zaujima hlavne z dovodu, ze mi pravdepodobne da moznost vytvorit si maly "embeded" system povedzme s Apache-2.2 a PHP-5.2, ktory nepresiahne 20-30MB aj s kernelom. Nieco take by sa hodilo.
Okrem toho je LFS dobry zaklad pre nove distro (tak vznikol tusim Arch, nad LFS sa postavil Pacman a Arch bol na svete).
Ale prevadzkovat a produkcne pouzivat takyto system - to si neviem predstavit.
No povedzme, ze vyjde nova verzia nejakeho doleziteho programu. Ten ale vyzaduje nove verzie existujucich kniznic.
Bude preto treba najskor prekompilovat kniznice a potom skompilovat samotny program. Co ak ale nove kniznice rozbiju zbytok systemu - bude treba upgradovat postihnute balicky - a uz sa to vezie ==> dependency hell.
Já to řešim tak, že všechny programy instaluji do adresáře /opt/název-aplikace. Je to pěkně přehledné, snadno konfigurovatelné (např. konfigurák samby je v /opt/samba/etc/smb.conf) a nahrazení nějaké aplikace novější je uplně v pohodě.
a jak to resite kolem knihoven? progra X potrebuje verzi knihovny A(1.0), program Y potrebuje verzi knihovny A(1.1), jak to udelate aby fungoval program A i B?
program X zkompiluji oproti A(1.0) a program Y oproti A(1.1) - no problem... ohledně tohoto byla již diskuse pod mým blogspotem, uživatel "pht" to krásně vysvětlil, snad se nebude zlobit když ho tu ocituji: "knihovny mají v názvu souboru obvykle čísla verze, symlinky pak mají v názvu souboru alespoň hlavní (major) číslo. Pokud skompiluju program proti názvu s přesnou verzí, tak bude vždy používat tuto verzi. Pokud skompiluju proti symlinku, což se obvykle dělá, bude po upgradu používat novou verzi. Ale jelikož symlink obsahuje hlavní číslo, a knihovny v rámci hlavního čísla verze bývají binárně kompatibilní, nestane se nic špatného. (Při ručním upgradu se přepíše symlink, ale starý soubor s přesnou verzí zůstává. Pouze v balíčkovacím systému se odstraní nejprv kompletně stará verze a pak se instaluje nová.)"
není problém mít v systému více verzí jedné knihovny... přiinstaluju prostě novou verzi knihovny a pak onen program - staré progamy používají starou knihovnu novej novou - žádný problém. Když jsem se do toho puštěl, tak jsem měl přesně z tohoto "problému" taky strach ale ukázalo se, že naprosto zbytečně, dependency hell je umělý konstrukt vznikající právě automatizovaným přístupem balíčkovacího systému distribucí. Při individuálním přístupu se toto dá ohlídat poměrně jednoduše...