Názory k článku Správa ručně kompilovaného software na Unixu
-
junix (neregistrovaný)Teda v popsane utilite nevidim zdny prinos. Akorat to symlinkuje, jinak to nic neusetri. prefix musim stejnak nastavovat rucne, tak to uz muzu prihodit i ten adresar s knihovnama do ldconfigu.
Nicmene s tim FreeBSD souhlasim. Ono instalace "ze zdrojaku" neni totez jako instalace "z portu". To je zasadni problem. Kdyz uz se pustite do kompilace "alien" softwaru primo ze zdrojaku, casto narazite na problemy s kompilaci, nebo konfiguraci. V tom vam zadny graft nepomuze.
Pritom FreeBSD obsahuje spoustu customizovanych Makefiles, ktere za vas tyto problemy ednoduse vyresi, jenze musite nejak tu "alien" aplikaci donutit, aby je pouzila. Pokud je nejaka aplikace s obdobnymi problemy v portech, pak muzete port vzit a upravit, ale jinak jste asi celkem v ... -
Bilbo (neregistrovaný)Jo, treba FreeBSD 6 a boost ... nektery veci tam chybi. QSA? Tam je qsa-1.1.2, nejnovejsi je 1.1.4 a (bohuzel) jako na potvoru opravuje pomerne zavaznou chybu. Takze i na FreeBSD je obcas potreba kompilace ze zdrojaku, i kdyz zase FreeBSD je na tom o dost lip nez treba OpenBSD (kde toho je pomerne dost malo, ale zase to neni zrovna "desktopove" BSD :).
A pokud chce clovek nejaky pomerne exoticky software ... tak jedine kompilace ze zdrojaku ... -
pharook (neregistrovaný)Stačilo dvakrát kliknout...
http://www.gormand.com.au/peters/tools/graft/graft.html#research -
anonymníV RPM-based distribucich mam docela dobre zkusenosti s http://asic-linux.com.mx/~izto/checkinstall/
-
Clock (neregistrovaný)V jakémkoliv systému nebo návodu může být chyba co ohrozí celý systém.
Když to člověk dělá manuálně a nesystematicky, tak si maximálně rozesere ojedinělý program, ale ne celý systém -> nenastávají havárie velkého rozsahu.
Proto mi nejvíc vyhovuje žádnou distribuci, LFS, stow ani nic takového nemít, jen mám /trash a napsal jsem si skript který přesouvá věci do trashe.
Je to sice víc práce, ale systém pak zabírá málo místa, je rychlý, up-to-date a nenastávají náhlé rozsáhlé havárie (jako gentoo mi třeba jednou zničilo gcc a portage takže se z toho nedalo dostat bez kopírování binárek z jiných mašin) -
JR (neregistrovaný)Pokud je kompilační/konfigurační prostředí aplikace v source tarballu založeno na auto* nástrojích (automake, autoconf, aclocal) - naprostá většina současných větších projektů - pak pro odinstalaci zpravidla stačí, za předpokladu, že se adresář se zdrojáky a již jednou "jetým" ./configure stále nachází na disku, do něj vlézt a zadat 'Make uninstall', a je vymalováno. Pravda, některé staré projekty neměly 'uninstall' target v Makefile dostatečně ošetřený, takže se stávalo, že za sebou zanechával "podsušky", ale sám jsem na něco takového již delší dobu nenarazil.
Protože používám Slackware podobně jako autor tohoto příspěvku, musím říci, že metoda, která se mi jednoznačně osvědčila (a mí kolegové, kteří používají distribuce řešící závislosti, jako Suse nebo Debian, to řeší defacto stejně), je prostě vytvořit si vlastní instalační skript, a instalovat software do /opt nebo /usr/local (v závislosti na tom, kterou verzi z FSH standardů vyznáváte :). Nic víc, nic míň. Uznávám, že v případě obřích projektů s mnoha závislostmi, jako je třeba VideoLan, je vytvoření SlackBuild skriptu (.spec souboru pro RPMisty) otravná dřina, ale v dlouhodobém horizontu se jednoznačně vyplatí (stačí již pak dělat v něm jenom změny), a management je jednotný. Mimo to, po světě existuje řada webů, kde lidé již nabízejí buildskripty pro programy, které v distribuci nejsou. Zkrátka takové "ports" pro Slackware. :)
Správa třetiny vybavení systému jedním nástrojem, další třetiny jiným, a další třetiny vůbec, za problémy s "ukočírováním" mnoha instalací, z nichž každá má instalovaných několik set balíků, za to prostě nestojí.
ČLÁNKY DO MAILU