OT: Proč OpenSource

Pavel Troller patrol@sinus.cz
Pátek Září 7 11:32:00 CEST 2007


> 
> Nevyresily uz tenhle problem davno balickovaci systemy jako je rmp nebo deb ?
> Instalce aplikace rozhaze sice soibory do ruznych spolecnych adresaru
> (jak je zvykem) ale diky instalaci z balicku se vi kteremu baliku ktery
> soubor patri, vi se jestli je to info nebo binarka nebo cfg a podle toho
> se s nim zachazi pri update nebo remove.
> 
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
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.
  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.
  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
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
tam nainstalovalo. Jak říkám, někdo více důvěřuje balíčkovači, ale já jsem
člověk, který co si neudělá sám (vlastní hlavou a rukama), není to pro něj
ono. A kupodivu mám už i pár desítek spokojených uživatelů a instalací, takže
úplná rarita asi nejsem :-).
  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.
Vzpomínám, jak jsem kdysi updatoval balíčkovačem jednu app na Sharpovi Zaurus
(do něj jsem si ještě tehdy nestihl vlastní distro vytvořit) a ono to řeklo, že
to potřebuje zupdatovat tuhle knihovnu a pak tamtu a pak glibc a pak 
Segmentation fault a byla z toho cihla, která se musela flashovat. Tak tudy
opravdu ne :-).
  S pozdravem Pavel Troller



Další informace o konferenci Hw-list