Upgrade (vsetkeho).

[Divacky Roman]

On Tue, Dec 28, 2004 at 11:01:29AM +0100, Dan Lukes wrote:
> Jozef Babjak napsal/wrote, On 12/28/04 07:39:
> >>	systemech je to zbytecne riziko. Navic, on ten upgrade "vseho" zase 
> >>	tak dlouho netrva ...
> >
> >  ^-- Ako robite "upgrade vsetkeho"? Vsetko (snad okrem cvsup-without-gui) 
> >zvyknem instalovat z portov, takze sa mi ako volba nuka portupgrade -arR
> >alebo nieco podobne. Avsak, pri instalacii mnohych aplikacii pouzivam
> >rozne volby ako -DWITH_XXX alebo WITHOUT_ULTRA_EXPERIMENTAL_FEATURE=yes;
> >portupgrade mi vsak iba nainstaluje/upgraduje port s defaultnymi
> >predvolbami, co je v niektorych pripadoch (napr. mc(1)) silne
> 
> 	1) portupgrade nepouzivam. Zakladem neni zadny racionalni duvod - 
> nezvykl jsem si na nej, proste.
> 
> 	Nicmene, vim tolik, ze portupgrade ma konfiguracni soubor a do nej 
> 	se tyto "specialni" volby pisou.
> 
> 	Nicmene, ja si stahnu posledni INDEX soubor od portu, spustim
> pkg_version -v | grep "<""
> 
> 	tim zjistim co neni uplne nove, to stahnu jako package (protoze ja 
> 	se v 90% pripadu bez zvlastnich voleb obejdu) a pro upgrade pouziju 
> pkg_update
> 
> 	Ono, system portu je docela pekny, ale mam-li udrzovat 15 pocitacu, 
> 	tak prekladat tentyz software patnackrat je zbytecna casova zatez. To bych 
> pak stejne delal tak, ze bych na jednom stroji vyrobil package (make 
> package) a na ostatni ho jen prenesl a znovu pouzil pkg_update. Ostatne, 
> tak to delam s temi balicky, kde si se zakladnimi volbami nevystacim.
 
portupgrade se da nakonfigurovat tak aby pouzival packages ne definovanem
stroji a "portupgrade -arRfPP" je pak velmi silna zbran...

(rozhodne vyrazne lepsi nez to delat rucne - a ano, dela to presne to co jsi
dane uvedl ze delas rucne)
 
> >	1) vyhodu: vsetko spolu dobre funguje
> >	2) nevyhodu: pouzivam starsi softvare, ako by som mohol
> >	3) nebezpecie: niektore aplikacie (najma sietovy demoni) 
> >neobsahuju posledne zaplaty. 
> >
> >Ako to riesite vy?
> 
> 	Body 2 a 3 jsou vlastne jeden bod. Ja to resim tak, ze jsem riziko 
> 	[1] vyhodnotil jako male v porovnani s rizikem plynoucim z [2,3].
> 
> 	Ono se mi totiz nijak bezne nestava, ze by balicky nefungovaly na 
> starsi verzi OS (tedy - o trochu starsi, alespon major cislo by melo byt 
> stejne). Pro systemove knihovny mnou drive zminena kompatibilita mezi 
> knihovnami stejneho major cisla totiz docela plati - rozhodne daleko 
> spolehliveji nez pro "third party" knihovny ...
> 
> 	Nicmene, nepredstavujte si, ze vsechno upgraduju vzdy jak se od 
> cehokoliv objevi nova verze. K upgrade pristupuji tehdy, kdyz to 
> potrebuji kvuli odstraneni nektere bezpecnostni chyby v nekterem 
> balicku, nebo kdyz potrebuju novou funkcnost obsazenou v nove verzi 
> nektereho balicku. Ale pak upgraduji vsechno - a typicky na vsech 
> produkcnich strojich ("domaci" a "testovaci" pocitace maji trochu jiny 
> rezim). Oba jmenovane duvodu ale tak casto nenastavaji.
> 
> 	Jestli mate dojem, ze v minulem a tomto dopisu si trochu protirecim 
> (minule jsem psal, ze mit system balicku nekonzistentni je zbytecne 
> riziko, kdezto dneska mi nevadi nekonzistence s verzi OS) tak ten dojem 
> je spravny. Nicmene, jsme to ja, kdo tu dost casto tvrdi, ze zadne 
> optimalni univerzalni recepty a pristupy neexistuji a sprava pocitace je 
> (i) vec zkusenosti - kterou ma kazdy trochu jinou. Moje drivejsi 
> zkusenosti me vedou prave k tomuto chovani.
> 
> 						Dan
> 
> -- 
> FreeBSD mailing list (users-l at freebsd.cz)
> http://www.freebsd.cz/listserv/listinfo/users-l