Vlákno názorů k článku Instalujeme software do vlastního LFS systému od Srigi - Osobne ma LFS zaujima hlavne z dovodu, ze...
-
Srigi (neregistrovaný)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. -
Srigi (neregistrovaný)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. -
Atrament (neregistrovaný)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á.)"
-
Atrament (neregistrovaný)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...
