Problem s udrzovanim programu v base

[Dan Lukes]

Tyman Vladimir napsal/wrote:
>>>>upgrade na posleni openssl). Co nejrychlejsi zahrnovani nejnovejsich
>>>>verzi cehokoliv do stabilniho systemu je spis hrozba nez vyhoda ...
> 
> 
> O tom jsem prece nemluvil ja mluvim o posledni stabilni verzi (verzi SW 
> z contrib adresare tedy, kterou nevyviji tym FreeBSD). Stabilni myslim,
> ze v ni jsou opraveny chyby a doporucuje ji k produkcnimu nasazeni 
> ten ci onen vyvojar bind - ISC, sendmail - sendmail.org, openssh - atd.)

	No, tak to skutecne mluvime o necem jinem.

	Ja mluvim o stabilni verzi systemu, coz pro me v konecnem dusledku je 
vsechno, co dany system zahrnuje. To napriklad znamena, ze system 
startup scriptu mi dany produkt spolehlive spusti, ze system nastavujici 
"standardni" prava adresaru je nastavi nebo ponecha ve stavu, kdy dany 
produkt bude fungovat, ze "security" spoustene kazdou noc bude umet i s 
danou verzi produktu poskytovat relevantni udaje.

	Jakmile jednou takovy system existuje, povazuji za prijatelny zasah do 
nej pouze opravy nalezenych chyb.

	To, ze nejaka komponenta systemu (v sirokem slova smyslu) vznikla v 
nove verzi, pricemz tato nova verze obsahuje "jen" nove feature, 
pripadne opravuje chyby, ktere se mohou vyskytnout jen na jinych 
systemech ja nevidim jako dostatecne silny duvod k zasahovani do 
funkcniho stabilniho systemu.

> Tento SW nevyviji vyvojari FreeBSD je pouze zahrnut do base systemu (byt mozna s urcitymi
> modifikacemi). Proto se mi zda normalni kdyz uz SW treti strany do base zahrnu
> tak bych mel prijmout reholi jeho aktualizaci tak aby odpovidaly stabilni verzi SW,
> kterou doporucuje k produkcnimu nasazeni sam tvurce prislusneho SW.

	To, ze producent nejakeho software doporucuje k nasazeni jeho posledni 
verzi je logicke a nedovedu si predstavit, ze by tomu bylo jinak.

	Nestaci prohlasit "mel bych prijmout reholi", protoze nekdo by se mohl 
zeptat proc - a ja se skutecne ptam proc. Prilis ne nezajimaji 
abstraktni duvody. Me zajimaji prakticke a konkretni duvody, k cemu je 
to dobre - protoze jen nad takovymi zcela konkretnimi duvody muzeme vest 
rozumnou debatu o tom, jak zavazne tyto duvody jsou. Nad abstraktnim 
prohlasenim "melo by se aktualizovat" bez zduvodneni proc je diskuse 
pomerne tezka a jen malo pravdepodobne nekam vedouci.

	Co se tyce "rehole", opakoval jste tento nazor jeste jednou nize  a 
proto svuj nesouhlas i vysvetleni sveho pohledu uvadim az tam.


> Pokud maintaineri base (zhruba to co je v /usr/src/contrib) nedrzi krok z vyvojem 
> tohoto SW tak co muzu jako uzivatel udelat aby to updatovali? 
> V portech jsou treba v tu chvili verze toho SW v poradku, ale v base ne.
> Nemel bych se ohanet tim ze na to nemaji cas, tak to pak nema byt v contrib.

	Ale ma to byt v contrib - v contrib je funkcni verze bez znamych 
bezpecnostnich chyb. To me pripada jako dobry vysledek. Samozrejme, 
mohla by tam byt posledni verze systemu a snad by to tak bylo i lepsi, 
ale ze bych to vnimal jako opravdu zasadni otazku, to tedy nevnimam ...

	Nicmene, otazka znela, co muzete jako uzivatel udelat - to je pomerne 
proste - poslat PR, ktere bude podrobne popisovat jak zakomponovat novou 
verzi do systemu, vcetne pripadnych patchu tech souvisejicich komponent 
systemu, ktere na dany produkt navazuji, ale nejsou jeho soucasti.

	Musite ovsem pocitat s tim, ze nejprve bude patrne zmena provedena v 
CURRENT a pokud nebudou hlaseny problemy, pak bude, patrne s odstupem 
(tim vetsim, cim vetsi bude zasah) prenesena do STABLE. Musite pocitat i 
s tim, ze nejprve bude muset nekdo z commiteru (o kterych se 
predpoklada, ze dokazou odhadnout dopady a navaznosti na system) tuto 
zmenu schvalit. A muze se stat, ze si zadny takovou zmenu schvalit 
netroufne a pak se zmena neprovede.

> Release tym je preci zodpovedny za system? Pokud se kdysi rozhodli, ze do base 
> zahrnou SW tretich stran tak na sebe vzali reholi jejich updatovani.

	To je teorie, na ktere se uplne neshodneme. Ja se domnivam, ze 
odpovidaji za to, aby udrzeli tu funkcnost, kvuli ktere byl produkt 
importovan.

> Pokud je skluz ve verzi portu tak presne vim na koho se mam obracet a hlavne si 
> to mohu rucne upgradovat sam (zasah do portu je jednoduchy) a take nemusim kvuli 
> tomu rebuildovat cely system.

	Zasah do systemu je, alespon dle mych zkusenosti, zhruba stejne slozity 
jako zasah do portu. Co se tyce rebuildovani systemu, to byste musel 
udelat take, i kdyby contrib updatoval team FreeBSD.


> Koho se mam jako uzivatel dovolavat kdyz chci zmenu v contribu na posledni stabilni
> verzi toho ktereho SW?

	Jaku u kazde jine pozadovane zmeny v systemu - PR.

> Uplne by stacilo, aby slo pri instalaci z CD vybrat, ze nechci openssh, sendmail, openssl
> atd. (viz options v make.conf) a tim na sebe jako uzivatel beru odpovednost za jejich instalaci 
> z pkg/portu. Pri instalaci z CD nemam sanci se zbavit techto veci. Tato zmena by snad az 
> tak zasadni nebyla.
> Doufam, ze uz je to jasnejsi :-)

	No, jasnejsi to je, je evidentni, ze spor se da zuzit ciste na otazku, 
zda tyto baliky maji byt soucasti systemu a tedy zahrnuty do celkove 
odpovednosti za jeho funkcnost, nebo tam byt zahrnuty nemaji (vcetne te 
odpovednosti).

	Ja osobne vidim radeji system se zarucenou (celkovou) funkcnosti nez s 
posledni verzi neceho, ale bez zarucene navaznosti na ostatni casti 
systemu, to je ale evidentne vec nazoru. Pokud tyto komponenty ze 
systemu nevidelime, pak nevidim jako ucelne pracovat na moznosti 
updatovat cast systemu prostrednictvim baliku, kdyz k tomuto ucelu uz 
slouzi cvsup. Pokud tyto komponenty ze systemu oddelime, z meho pohledu 
to situaci v systemu zhorsi, protoze nikdo uz nebude garantovat 
spolupraci systemu jako celku s touto komponentou (to je totiz prave 
zasadni rozdil mezi moduly uvedenymi v ramci systemu v contrib a porty).

	Ja rozhodne preferuji celkovou stabilitu celeho systemu (v sirokem 
smyslu toho slova), kdezto vy podporujete predevsim "posledni verze 
komponent". To nemusi byt nutne v konkretnich pripade v rozporu, ale je 
videt, ze to rozhodne neni totez.


> Pokud to tak je tak uz vubec nechapu proc je bind soucasti contrib rep. base a proc ho tam release tym drzi.

	Protoze tim ma jeden DNS server, ktery je navazan na system, na jeho 
konfiguracni soubory a celkovou filosofii, takze je snadne je 
rozfungovat a je jistejsi, ze bude fungovat dobre a bez problemu. Nic z 
toho "port" system nezarucuje a nektere veci neni schopen zajistit z 
principu.

	Ano, cena za tohle je, ze v systemu neni posledni verze BINDu - protoze 
system nezarucuje, ze v nem bude posledni verze BINDu, ale ze v nem bude 
nameserver nejakych vlastnosti a ten tam je.

	Me to pripada dobry vysledek, lepsi, nez kdyby tomu bylo obracene.

	Je ale pravda, ze to plyne z toho zakladniho, na cem jsme se neshodli - 
na tom, jestli je podstatnejsi "overena funkcnost", nebo "posledni verze".

	Nic z vyse receneho nebudiz chapano tak, ze vas odrazuji od "vasi 
cesty". Jen rikam, ze ja ten problem zdaleka nevidim jako tak vazny a 
tedy prioritu jeho reseni tak vysokou. To samozrejme a nepochybne 
souvisi s timj, ze ja prakticky nikdy nepotrebuji k cemukoiv realnemu 
"posledni verzi".

					Dan


-- 
Dan Lukes      tel: +420 2 21914205, fax: +420 2 21914206
root  of FIONet,  KolejNET,  webmaster  of www.freebsd.cz
AKA: dan at obluda.cz, dan at freebsd.cz, dan at kolej.mff.cuni.cz