OT: Proč OpenSource

[Petr Simek]

On Fri, 7 Sep 2007, Pavel Troller wrote:

> Zdravím,
>   ano, samozřejmě že vyřešily, ale to právě je možná "package-friendly", ale ne
> "user-friendly", alespoň pro usera/admina, jako jsem já.
>   Problém je v tom, že to sice ví balíčkovač, ale neví to nikdo jiný, dokud se
> nezačne hrabat v těch databázích a zkoumat, kde co má být. Další problém je, že

No pozor to neni tak hrozne -

  rpm -ql installed_package    vypise soubory patrici balicku
  rpm -qf /path/file           vypise balicek do ktereho soubor patri

> ta databáze je společná, což mi už začíná zavánět dříve diskutovanými registry.
> Slyšel jsem povídat spoustu věcí o tom, co se stane, když se naboří databáze
> instalátoru. Prý je to na úplnou reinstalaci, těžko se to léčí. Naštěstí to
> neznám z vlastní zkušenosti, neboť v mém systému nic takového nemám.

To je problem ale ne zas takovy - pokud pravidelne zalohujete lze ty soubory
obnovit. Zatim se mi to nikdy nesalo za chodu, snad jedine kdyby se zboril
disk. Pokud by mi to 'ruplo' pri instalaci nejakeho balicku a databaze se
naborila, musel bych ji obnovit ze zalohy a balicek nainstalovat znovu pres
--force aby ho tam dal i kdyz jeho soubory jiz existuji.

>   Další zásadní výhrady mám k tomu společnému "jutovému pytli". Třeba v mých
> instalacích je /opt prakticky vždy samostatný partition, stejně jako /home
> nebo /var. Snižuje se pak nebezpečí, že když něco selže, smaže to všechno
> dohromady, i seriózní disk crash se obvykle omezí jen na jeden partition a tak
> nemusíte obnovovat úplně všechno.

Pokud jsou ty partition na jednom disku tak bych nebyl tak optimisticky.
Zaznamenal jsem i opacny trend - vsechno v / stejne bud to funguje nebo
odejde disk a pak je vsechno v pytli. Tim delenim na partisny si clovek
akorat vytvari omezeni co se tyce vyuzitelnosti disku. Duvodem proc to
musi byt rodelene je napriklad zavedeni diskovych kvot pro uzivatele, tam
to na adresar nejde.

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

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

>   Jediné, co můj systém neřeší, jsou dependence - pokud nějaký balíček (třeba
> něco do KDE) vyžaduje jiné balíčky (základ KDE, Qt, X11...), je na adminovi,
> aby je tam všechny natahal, samy se mu nenatahnou. A to je můj záměr.

No to je jedna z veci ktere mi prave vyhovuji ze nemusim nic natahat. Napisu
'yum install package' a on zjisti zavislosti a napise mi ze  krome toho
baliku musi nainstalovat jeste X dalsich - vypise jejich seznam. Ja se pak
muzu rozhodnout jestli chci pokracovat nebo ne.

Nekdy to byva provazane az prilis takze pro pouziti nejakeho programu ktery
podporuje spojeni i na jiny program se doinstalovavaji knihovny toho jineho
programu i kdyz Vy vubec nezamyslite jej vyuzivat. I tak je ten yum dobry -
rekne Vam vsechny zavislosti, vy si ty balicky muzete postahovat a
nainstalovat rucne (krome toho ktery nechcete) a pak ten kvuli kteremu to
delate nainstalovat pres --nodeps a ten balicek na kterem to zavisi a ktery
nechcete tam mit nemusite. Obvykle to beha.

>   S pozdravem Pavel Troller

S pozdravem

*------------------------------------------------------------------------*
|                          Petr Simek   APS JU                           |
|                             psimek@jcu.cz                              |
*------------------------------------------------------------------------*