Vylepšenia v Linux Mint Debian na pomoc s rolling updates

Keďže pri rolling-updates môže po aktualizácii nastať problém, kde skúsený používateľ si poradí a neskúsený nie, Linux Mint Debian prichádza s vylepšením. Zriadili nové vlastné repozitáre a prerobili aplikáciu Update Manager. Repozitár „Latest“ raz do mesiaca zmrazí Debian Testing a poskytne ucelený aktualizačný balíček (ten bude mať vlastné poradové číslo). Za ten mesiac buď prípadné chyby odstráni tím Debianu, alebo bude mať tím Mintu čas zverejniť informáciu či workaround. Tieto informácie budú potom zobrazené priamo v programe Update Manager.
Repozitár „Incoming“ pre odvážnych používateľov bude podradený Debianu-Testing a nadradený nad „Latest“. Naďalej bude možné používať priamo repozitár Debianu.

6.7.2011 22:15 | Andrtalec | Komunita

Komentáře

[pushkin]

Že by objev Service Packů?

[Mrkva]

eďže pri rolling-updates môže po aktualizácii nastať problém

Otázka do pléna - kdy jste naposledy na takový problém narazili?

[Deafboy2v1]

Nepoznas adrenalinovy sport menom Arch? Nejaku dobu som ho pouzival. Bol skvely, ale pri kazdej vacsej aktualizacii mi tuhla krv v zilach. Nasledovala sprska vulgarizmov, potom google, a na zaver ten hrejivy pocit ked sa vsetko vratilo do normalu... alebo aj nie :)

[Mrkva]

Arch jsem zkoušel a přišel mi takový no...

Ale jedu na Debianu Sid (taky rolling updates) a naprosto bez problémů :)

[ne-nerd]

wtf? Bezim na archu uz niekolko rokov. Za ten cas sa vyskytlo tak do 10 problemov co bolo nutne riesit. Vacsina z toho bola chyba v programoch a nie balikoch ako takych. Celkom by ma zaujimali tvoje problemy, ktore si mal (konkretne).

[Václav Kramář]

Z toho si nic nedělej. Takových fám kolují v diskuzích tuny. Taky jsem za víc jak 3 roky užívání potkal jenom 1 chybu (v aplikaci/upstreamu, v balíčku/Archu žádnou). Pak jsem si na pár měsíců odskočil k distribuční turistice (pro oživení přehledu) a teď váhám, jestli nahodit CentOS (pro jeho konzervativnost a 7letou podporu), nebo se vrátit k Archu (pro jeho čistotou a aktuální ovladače/Mesu (Radeon X1250 a Radeon Xpress 200M)).

[pavlix]

S tím CentOSem počkej aspoň na šestku.

[Václav Kramář]

To přesně dělám. A čas si krátím hraním s Fedorou 15 s Gnome 3. Ale pořád vrtá červíček pochybností. Konzervativnost CentOS se 7letou podporou je super, ale čistota a aktuálnost Archu má taky něco do sebe...

[little.owl]

Porad mi vrta hlavou ta cistota .... co to jako ma v danem kontextu konkretne byt?

[Václav Kramář]

Pro mně:

1. Vanilla verze aplikací kde to jen jde (naprosté minimum patchů => minimální riziko zanesení nových chyb).
2. Jednoduchý a přehledný konfiguráky.

[Michal Kubeček]

Ad 1: v případě patchů přidávajících nebo měnících funkcionalitu máte pravdu. Většina distribučních patchů jsou ale naopak právě opravy chyb těch vanilla verzí. Námět k zamyšlení: myslíte si, že enterprise zákazníci si raději platí ne zrovna levnou podporu sedm (i více) let starých distribucí místo upgradu na novější jen proto, že nevědí co s penězi?

[Václav Kramář]

Podívej se na komentáře výše: proti enterprise/lts nic nemám a chápu, že tam to bez patchů nejde. Vanilla považuju za výhodu u rolling release a short term support. Zkrátka si musím hodit korunou mezi konzervativností CentOSu a aktuálností Archu. V daném případě bohužel nemá ani jeden z těchto dvou přístupů prokazatelně navrch. Zatím je to CentOS:Arch 51:49 .

[pavlix]

Podle mě, člověk, který se nemůže rozhodnout mezi těmito dvěma extrémy, vůbec neví, co chce. Neřeknu rozhodovat se mezi podobnýma možnostma, ale nevědět jestli chci extrémně konzervativní nebo extrémně divokou distribuci... :), to se fakt divím.

[Václav Kramář]

Obě varianty fungují výborně, takže proč ne... Ale asi vyhraje konzervativnější cesta.

[pavlix]

Vanilla verze aplikací kde to jen jde (naprosté minimum patchů => minimální riziko zanesení nových chyb).

To je nesmysl, ty patche jsou přímo ve vanilla aplikacích :), každá verze se liší od té předchozí. Patch jako patch, akorát u distribucí se často pomocí patchů hlídá kvalita a zabezpečení.

Takže osobně bych řekl, že je to spíš naopak, než píšeš.

Jednoduchý a přehledný konfiguráky.

Jedny z nejlepších bývaly na gentoo, včetně konfigurace, jak se má co zkompilovat. Takže jo, to bych ještě dokázal pochopit. Ale redhatí a debianí distribuce mívají konfiguráky taky dobré.

[little.owl]

ad 1) Jsou to vetsinou patche, ktere fixuji bugy. Backporty driveru jsou take spise pozitivni veci, nebot mate podporu novejsiho HW a stabilitu predchozi verze - nemusite jit do bleeding edge Vanilla.

ad2) To je jsem cekal a je to podle mne totalni a tisickrat opakovana hloupost, klise. Configuraky vetsiny distribuci jsou stejne a pokud ma nekdo problem se startup systemy vetsiny mainstreamovych distribuci z pohledu "slozitosti" ci "neprehlednosti", mel by uvazovat o zmene profese nebo si najit jiny konicek. Stejne nakonec vetsina distribuci bude pouzivat systemd.

[pavlix]

ale čistota a aktuálnost Archu má taky něco do sebe...

Já tam žádnou čistotu nevidím :).

[little.owl]

Jak dlouho jeste ....... ? :-/

[pavlix]

Mně se neptej, ale v tuhle chvíli bych CentOS 5 na něco, co chci používat po dobu několika let, nenasazoval. To už bych se radši ohlížel po Scientific Linux.

[Václav Kramář]

Už (snad) moc ne. Viz http://qaweb.dev.centos.org/qa/node/105.

[Michal Kubeček]

Co mne tak namátkou z hlavy napadá jako potenciální zdroje problémů, které je/bylo potřeba dořešit ručně:

• přechod na libata drivery u IDE zařízení
• přechod X.org na HAL a zase pryč
• v podstatě jakýkoli upgrade na dostatečně nové jádro, používají-li se closed source NVidia/ATi drivery
• totéž pro VMware
• upgrade KDE 3.5 na 4.x
• některé upgrady KDE 4.x na 4.(x+1)
• přechod PHP ze systémových časových zón na vlastní

[Václav Kramář]

přechod na libata drivery u IDE zařízení

Více méně upstream. Řešení: UUID nebo LABEL.

přechod X.org na HAL a zase pryč

Opět spíš upstream. I když (vzhledem k dopadu) to asi šlo vyřešit elegantněji.

v podstatě jakýkoli upgrade na dostatečně nové jádro, používají-li se closed source NVidia/ATi drivery

Čistě upstream. Arch není z distribucí, které by všechno dělaly za administrátora. Jenom mu dávají do ruky dobré nástroje. Použití je na něm.

upgrade KDE 3.5 na 4.x

některé upgrady KDE 4.x na 4.(x+1)

Opět upstream.

Všechny 3 přístupy (konzervativní release cycle (Debian Stable, RHEL,...), rychlý release cycle (Fedora, Ubuntu,...) a rolling release) mají své výhody a nevýhody. A každý z nich je vhodný pro jiného uživatele. I když upřímně řečeno, "zlatá střední cesta" (půlroční rychlokvašky) mi v tomhle případě moc zlatá nepřijde. Mám pocit, že spojuje nevýhody z obou konců spektra, aniž by přinášela nějaké výhody.

Na server nebo pracovní stanici bych rozhodně volil velmi konzervativní přístup: Debian Stable, RHEL/CentOS, SLED/SLES. Totéž v případě počítače pro BFU, kterému budu zajišťovat občasnou administraci a support. Pro desktop pokročilého uživatele s touhou po novinkách, dostatkem času a chutí "vrtat se ve střevech" bych sáhl po rolling release: Arch, Debian Testing. Pro experimentátora ("early adopter") potom Arch Testing nebo Debian Unstable.

[pavlix]

No... kdybych se rozhodoval jenom podle toho, pravděpodobně bych sáhl po rolling updates, ale při zvážení dalších okolností jsem stejně u Fedory. Co si budem povídat, od rolling updates moc daleko nemá :).

[michich]

Více méně upstream.

Ano, tyto změny přicházejí z upstreamu. Ale jak to souvisí s diskutovaným tématem? Tj. že takováto změna může k uživateli s rolling updates dorazit kdykoliv, narozdíl od distribuce s definovanými releasy, kde jsou takto radikální změny v rámci jedné verze nepřípustné.

[little.owl]

Presne. U distribuci s rolling updates se mi system muze rozbyt v podstate kdykoliv, obvykle v dobe kdy to nejmene potrebuji a nemam cas veci resit; u pravidelne releasovanych dister se to nestava. Navic pokud neco opravdu programuji, potrebuji stabilni prostredi a ne resit regrese vznikle zmenou verzi knihoven a nastroju.

[pavlix]

Navic pokud neco opravdu programuji, potrebuji stabilni prostredi a ne resit regrese vznikle zmenou verzi knihoven a nastroju.

Kdysi, když jsem začal vyvíjet, tak jsem si kvůli tomu místo Debianu dával Gentoo :). Když něco opravdu programuješ, často musíš myslet dopředu a potřebuješ bleeding edge. Někdy zas potřebuješ konzervativnější verze. Jindy dokonce naprosto konkrétní verze. Gentoo bylo jediný distro, který tohle zvládalo (většina software a knihoven v několika verzích dozpátku, stačilo si vybrat).

Původní plán byl používat ho jen v chrootu, nakonec jsem ho měl několik let na desktopu a část z toho na domácím serveru.

[little.owl]

Ano, ze kazdy mame jine pozadavky. Ja se vrtam v embedded systemech a klicova je pro me reproducibilita, regrese a QA.

[pavlix]

Právě kvůli embedded systémům jsem gentoo nasazoval :). Potřeboval jsem testovací OS, do kterého co nejjednoduššeji dostanu stejné či aspoň blízké verze software jako jsou na cílové platformě.

[Michal Kubeček]

Asi jste nepochopil smysl mého příspěvku. Všechno to, co jsem uváděl, samozřejmě vyřešit umím a samozřejmě vím, že ty nekompatibilní změny mají původ v upstreamu. Ale každá distribuce, nechce-li ustrnout navěky na historických verzích, ten krok dříve či později udělat musí. Uvádím to jako pár příkladů toho, s čím si zcela určitě neporadí automatický update (nechcete-li riskovat, že v 90 procentech případů to zvládne hladce a ve zbylých 10 procentech konfiguraci zmrší do nepoužitelna) a velmi pravděpodobně si s tím neporadí nezkušený uživatel.

[Foo Bar]

Co ovšem koukám ještě někdo nepochopil, že Debian Testing není rolling update. A může se stát, že neopravený balík může v Testingu hnít docela dlouho kvůli závislostem nebo nedostatku času DD. Viz např. mysql-5.1, kde verze 5.1.49-3 byla v testingu od 2010-12-04 do 2011-06-17 i přesto, že zmigrovaným balíkům, které byly zkompilovány s novější verzí, chyběl symbol. A novější verze ne a ne propadnout do testingu, protože mysql-5.1 nešlo zkompilovat pomocí gcc-4.6 (resp. šlo, ale segfaultovalo), a nobse neměl čas. Aby se problém ještě vylepšil, tak věci zkompilované oproti 5.1.57-1 pro změnu do testingu nemigrovaly vůbec asi měsíc včetně bezpečnostních oprav.

Takže pozor, Debian testing opravdu není rolling... protože se někdy vůbec nekutálí. (Což neznamená, že se o tom, jak udělat rolling-updates v Debianu nediskutuje.)

[Mrkva]

Já měl na mysli Sid (aka unstable), ne testing :)

[Foo Bar]

Vy možná ano, ale příspěvek, na který jsem reagoval, obsahuje větu:

Pro desktop pokročilého uživatele s touhou po novinkách, dostatkem času a chutí "vrtat se ve střevech" bych sáhl po rolling release: Arch, Debian Testing.

A Debian Sid je na tom chvílemi ještě hůře :). Zvlášť, když se mi do něj povede poslat nějakou hodně velkou pitomost ;).

Ale je pravda, že to před lety bývalo horší (nejhorší byla asi migrace z libc5). (A sám mám na desktopu Ubuntu, na vzdálené balíkovací stanici Debian squeeze+backports, a v pbuilderech všechno možné :)).

[Petr Ježek]

Na Mintu stačí v případě systémových/userspace zvěrstev jako byl (je) HAL autoritativně "ponechat/odebrat_a_nahradit". Ostatně při aktualizacích je těch informačních a rozhodovacích prvků pro zasvěcené celkem dost. Na Archu je již delší dobu spolehlivá kombinace hlášek pacmana (dotazy před náhradou, komentáře po instalaci), zpráv na webu a aktualizačních úprav wiki. Pochopitelně pomohou i maitaineři přímo v diskusích, pokud to není zjevně mezi klávesnicí a židlí... Soudný člověk neupgraduje molochy typu KDE, dokud neuplyne alespoň standardní půlrok na vychytání největších nedodělků (KDE je oproti jiným DM/WM skutečný supersystém s mnohem vyšší citlivostí na úplnost a spolupráci komponent). No a k ručnímu doladění? Bez "ručních" úprav se v technice žádný uživatel neobejde, pokud jde o složitější systém. Pro ty, co tomu nerozumí, slouží jednodušší systémy.

[Jablíčko]

Přibližně v únoru tohoto roku. Aktualizoval sem svůj Debian Testing asi po čtyřech měsících a od tý doby se spousta věcí neustále rozbíjí a snad každej upgrade řeším nějakej problém. Některý se sice občas aktualizací opraví, ale zpravidla se objeví zas něco dalšího. Se systémem sem nikdy nedělal žádný opičárny a víc než rok a půl sem se nemusel v podstatě o nic starat.

[Petr Ježek]

Pokud systém funguje, rozumným důvodem aktualizace je pouze testování nebo nezbytnost využití funkčně bohatší nové verze. Vše ostatní spadá pod vady ve funkčnosti (včetně bezpečnostních aktualizací), kde občas může jedna oprava vyvolat nezbytnost jiné... To je NORMÁLNÍ a pochopitelné, člověk není dokonalý.

[Foo Bar]

Debian nedávno přešel na:

- gcc-4.6

- novější eglibc

- novější perl

- multiarch

Můžete si vybrat :)

[Jablíčko]

Hmm, to nevím, největší a stále se vleklý problém mám s vykreslováním. Napřílkad po suspendu xterm, okular, opera, full-screen flash mají problémy s překreslováním. Ostatní problémy sem skoro vždycky nějak vyřešil, nebo odešly samy. Problém je, že se tohle blbě debuguje a řešení se mi nepodařilo vygooglit. (A že mi teď přestal jít tisk a hdapsd ještě nějak zvládnu ) Nemám moc čas to řešit, za nějakou dobu na to sednu pořádně a buď to vyřeším nebo prostě nahodím stable.

[Foo Bar]

No tak to vám bohužel neporadím... ale bugreportem (po tom, co ověříte, že už to není nahlášeno) toho moc zkazit nemůžete. Hádám, že dnešní Xorg je trochu přívětivější, než když Branden Robinson měl na stránce balíkovačů Xek tenhle obrázek: http://pics.livejournal.com/twoflower/pic/00023gph/g6

:)

[hajma]

Je v nektere distribuci pouzitelna alternativa solarisich boot environments?