OT: Proč OpenSource

[Pavel Troller]

Zdravím,
  s ostatními body, na které jste reagoval, v podstatě souhlasím, můžete na to
mít tento názor. Já zvolil své řešení, protože mi vyhovuje a zdá prostě
odpovídá mým představám.
> 
> >   Já to tedy řešil ve své distribuci tak, že samozřejmě vytvářím pro své
> > uživatele binární balíčky, ale jsou to úplně obyčejné .tar.bz2 archivy, které
> > se dají snadno rozbalit do /opt (nebo do /opt64, což je u mne legální místo
> 
> No jo ale dalsi vyhoda kterou tam nemate a kterou rpm nabizi je specialni
> chovani v pro urcite typy souboru. Napriklad se souborem ktery je oznacen
> v baliku jako konfiguracni se naklada specialnim zpusobem - kdyz delate
> update tak se napred podiva jestli byl zmenen proti puvodnimu baliku, kdyz
> ne tak ho preplacne novym, kdyz ano tak ho necha byt a novy konfigurak Vam
> nakopiruje veldel s priponou .rpmnew . To same kdyz balik odinstalujete -
> pokud jste zasahl do konfiguraku neodstarni ho ale prejmenuje na priponu
> tusim .rpmold takze neprijdete o svoje upravy . To asi Vas zpusob neresi ?
> 
Ale řeší, ikdyž ne automaticky.
Doporučený způsob update balíčku je tento:
cd /opt
mv package unused # Existuje adresar /opt/unused, ve kterem se nic nehleda a
                    kam se davaji nepouzivane balicky
tar xIvvf package-new.tar.bz2
... a pokud má v sobě package adresář etc, tak je nyní možné např.
cd package
mv etc etc.new
cp -a ../unused/package/etc .
.. a mám starou konfiguraci v novém balíčku. Samozřejmě je možné i lepší
řešení, např. uschovat si starou konfiguraci už v momentě, kdy ji edituji,
pak použít diff, a vzniklý soubor pomocí příkazu patch aplikovat na nový
balíček, čímž dojde k aplikaci změn konfigurace (takhle elegantně to podle
mne neřeší ani ten automatický balíčkovací systém).
Pokud se náhodou nový balíček neosvědčí, stačí
cd /opt
mv package unused/package.bad
mv unused/package .
... a mám opět starý balíček plně online i s původní konfigurací. Zdá se mi
to jednodušší, než ho nějak lovit z rpm či kdoví odkud.

A pokud neupdatuji package binárně (což já nedělám, to dělají jen mí
useři), ale rekompilací, tam tam se obvykle existující konfigurační
soubory automaticky nepřepisují.

> > na 64bitové balíky) a i těmi nejprimitivnějšími nástroji (ls, midnight...)
> > má pak uživatel takový balík zcela na dlani a ví naprosto o všem, co se mu
> 
> No pokud mam ten rpm balik jako soubor tak se do nej pred instalaci muzu
> taky podivat jake obsahuje soubory a pokyny pro instalaci. Treba zminovany
> mc do toho umi krasne vlezt.
> 
> Navic prave src.rpm baliky jsou pro tvorbu distribuce docela pekny system -
> obsahuji zdrojaky a spec soubor ktery rika jak se maji rozbalit, jak se maji
> upravit, jak se maji zkompilovat a ktere vysledne soubory te kompilace se
> maji zaclenit do vysledneho rpm baliku a kde bude jejich vysledne umisteni.
> Takze neni problem delat dobre zdokumentovane upravy nebo rozsireni zdrojaku
> prave pomoci toho balickovaciho systemu.

O tom vím, již jsem uvažoval, že si adaptuji pro svoji potřebu genťácký emerge.
Tahle metoda je mi vůbec nejbližší, protože automaticky počítá s instalací
pomocí kompilace.

Zdraví Pavel Troller