Názory k článku
Správa ručně kompilovaného software na Unixu

Kvuli hromadne kompilaci jeste nebudu pouzivat Gentoo ci SourceMage. U tech stejne musite pockat, az vyjde dany ebuild ci spell (ackoli to nemusi trvat dlouho), ne? Pouzivam Slackware a tam je toto na dennim poradku.

taky me stve vecne opravovany linux. na bsd mi staci jeden exploit na nekolik let :)

:) presne, uplne s tebou suhlasim FreeBSD a porty

No....ono pokud by jsi používal FreeBSd, tak by jsi zjistil, že v portech není zdaleka vše co by jsi chtěl použít a navíc některé porty nejsou aktuální....

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 ...

tak nepouzivej "alien" aplikace, nebo se smir s tim, ze kdyz to pro tvuj system neni, tak yto pro nej proste neni - tj. pouzivej neco jineho, nebo se vyporadej s "asimilaci" ;)

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 ...

vacsinou nebyva problem kontaktovat maintainera ohladom aktualizacie portu..

Jak se to lisi od stow ?

Stačilo dvakrát kliknout...
http://www.gormand.com.au/peters/tools/graft/graft.html#research

Pokud si někdo dá námahu s tím, aby si udržoval distribuci sám, tak je skoro lepší, aby si napsal i vlastní nástroj na správu. Zmiňované prostředky sice ulehčí práci ze začátku, ale časem je člověk začne beztak předělávat a upravovat, aby více vyhovovaly současnému stavu.

Taketo nieco budem teraz mozno potrebovat.

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)

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í.

"instalační skript" má být "buildskript pro balíkovací systém použité distribuce, vytvořit na základě něj balík"