Dotaz: Debian testing - chybne zavislosti v distribuci?

[MartinB]

Cas od casu narazim ve verzi testing na zadrhel s balicky po updatovani seznamu - po chvili zkoumani jsem dosel k zaveru, ze spravci distribuce nahradili nektere knihovny jejich novejsimi verzemi, ovsem nekterym balickum zustala zavislost na jejich starsi verzi. Deje se tak proto, ze se u knihoven nezmeni jen verze, ale i jmeno balicku (napr. kdelibs3x -> kdelibs4x). Problem nastava v okamziku kdy upgraduji - nainstaluje se novejsi verze knihoven, stara zmizi a s ni i zavisle balicky, coz by jeste slo resit upgradovanim az v momente, kdy to chlapi na debian.org opravi, ale trochu se tim ztraci to kouzlo jednoduche a bezstarostne udrzby debianu a tyto problemy bych cekal spise v edici unstable. Vetsi potiz je ale s tim, ze inkriminovane balicky nelze nainstalovat (dokud to bude opraveno) na nove instalovany system. Ted napriklad v testing distribuci vubec neni kdevelop a k3b (nenasel jsem), ve stable i v unstable jsou. Co s tim? Testing jsem byl zvykly instalovat z minimal CD+net, protoze nasledny upgrade by stejne stahoval temer vsechny balicky s cerstvejsimi verzemi, ale takhle to nejde provozovat. Cca pred mesicem zase neslo instalovat KDE kvuli stejnemu problemu, ted uz je to opravene, ale zase nejdou jine balicky.

Odpovědi

[z]

mám pocit, že to je více méně problém jen s KDE, tak to tak strašný problém snad není, ne?

[Lynn]

jj, uz jsem na tohle tema si i zablogovala, treba postrehy z diskuze trosku pomuzou
http://www.abclinuxu.cz/blog/hell/2005/11/3/107812 mozna se muze hodit i tohle: http://www.abclinuxu.cz/forum/show/106143

Ted napriklad v testing distribuci vubec neni kdevelop a k3b (nenasel jsem), ve stable i v unstable jsou. Co s tim?

http://www.abclinuxu.cz/blog/hell/2005/11/3/107812#16

[MartinB]

Dekuju za linky, blogy jsem neprohledlaval. Jen doplnek - neprovadel jsem dist-upgrade, ale jen upgrade.

Takze shrnuti:
Pouzivam-li testing a a)instaluji ze site nebo b)pridavam nejaky balicek via apt, muzu se kdykoliv dostat do teto prekerni situace. Pak mi zbyva:

1) cekat, az to soudruzi na z debian.ndr opravi (coz je vesele zejmena u nove instalovaneho systemu, protoze to vetsinou trva tak mesic)
2) rucne kuchat a upravovat zavislosti balicku (ale z nejakeho duvodu na prislusnych verzich asi zavisi, ne?)
3) vselijak kombinovat testing/unstable atd., zkoumat jednotlive zavislosti a knihovny a nejak to rucne primet k fungovani
4) vykaslat se na vecne rozhaseny balickovaci system a vsechno kompilovat

Body 2-4 jsou obzvlaste vesele pro nekoho, kdo debian/testing provozuje na desitkach stanic (tedy pro mne). Doma si s tim klidne budu cely vikend hrat, ale tohle byl duvod, proc uz par let presvedcuji vsechny kolem o debianu - dokonaly sytem balicku a updatu. To je to, "proc Debian"! Samotne jadro+aplikace jsou ve vsech distribucich stejne, jde jen o to jak to ta ktera zastresuje a spravuje verze.

Inu chybami se clovek uci. Zaverecne resume pro mne - Debian pouze stable (kdo spravuje vice nez jeden server potvrdi mi, ze v podstate neni lepsi volba) a na stanici, kde clovek potrebuje jakz takz cerste balicky ... asi neco uplne jineho nez linux, jinak se v tom proste vzdycky budete muset vrtat, coz lze provozovat na jednom (svem) stroji, ale mate-li podporovat par desitek masin v praci plus samozrejme sve okoli pribuznych a znamych - nelze. Sbohem Deborah-Iane, mel jsem te rad.

[martink]

Ono je to trošku jinak. Závislosti v testingu jsou v pořádku, "soudruzi" nemají co opravovat. Takže při čerstvé instalaci na žádný problém nenarazíte.

Problém můžete mít jen při upgradu, kdy váš systém obsahuje balíčky, které zrovna v testingu nejsou (občas se při nějaké velké změně některé "brzdy" nachvilku odeberou). Tyto balíčky mohou záviset na nějakých starších knihovnách, které jsou v konfliktu s některou aktuální knihovnou.

Pak vám zbývá problémový balíček odinstalovat nebo upgradovat z jiného zdroje. Přímo se nabízí unstable, kde opravdu nic zkoumat nemusíte. Stačí přidat nachvilku zdroj unstablu, zabezpečit aby se neupgradoval celý testing, nainstalovat požadovaný balíček a zase zdroj unstablu odstranit.

Nebo si můžete stáhnout ten v testingu momentálně neexistující zdrojový balíček ze snapshots.debian.net a jednoduše z něj vytvořit binární balíček se správnými závislostmi (prostě dpkg-buildpackage ...).

A nebo postupovat tak, jak postupují uživatelé distribucí bez 16000 ready-to-install balíčků...

A to loučení s Debianem... No na můj vkus docela teatrální ;)

[MartinB]

Ono je to trošku jinak. Závislosti v testingu jsou v pořádku, "soudruzi" nemají co opravovat. Takže při čerstvé instalaci na žádný problém nenarazíte.

Zrejme jste necetl moje (a nejen moje) vzlykani pozorne - napr. K3B se proste v soucasnem testing vubec nenachazi, tzn. budu-li instalovat z minimal-CD, na kterem je jen hrstka nejnutnejsich balicku a zbytek budu chtit tahat z netu (moje obvykla instalace) - jsme tam. Druha cesta k temuz je, chceme-li nainstalovat nejaky novy balicek ... ale to bych se opakoval, viz muj puvodni prispevek.

některé "brzdy" nachvilku odeberou).

Ano, napr. v pripade KDE (resp. balicku kamera, na kterem toho zaviselo docela dost) to bylo pres mesic

Přímo se nabízí unstable, kde opravdu nic zkoumat nemusíte. Stačí přidat nachvilku zdroj unstablu, zabezpečit aby se neupgradoval celý testing, nainstalovat požadovaný balíček a zase zdroj unstablu odstranit.

Ano, to jsem uvadel jako jeden z bodu, jak to vyresit. Vcetne toho, proc me to irituje - to je duvod, proc nepouzivam jine distribuce.

Nebo si můžete stáhnout ten v testingu momentálně neexistující zdrojový balíček ze snapshots.debian.net a jednoduše z něj vytvořit binární balíček se správnými závislostmi (prostě dpkg-buildpackage ...).

Vy jste to vazne necetl :o) (nic ve zlem)

A nebo postupovat tak, jak postupují uživatelé distribucí bez 16000 ready-to-install balíčků...

Souhlasim, tohle JE argument. Nic lepsiho jsem bohuzel zatim nenasel.

A to loučení s Debianem... No na můj vkus docela teatrální ;)

Jsem uz takovy, kdyz neco zklame moje ocekavani, upadam do patosu a teatralnosti ;)

[martink]

napr. K3B se proste v soucasnem testing vubec nenachazi, tzn. budu-li instalovat z minimal-CD, na kterem je jen hrstka nejnutnejsich balicku a zbytek budu chtit tahat z netu (moje obvykla instalace) - jsme tam

Asi si nějak nerozumíme. Že v testingu není v současné době K3B je sice smutné, ale jak to souvisí se závislostmi? Prostě se mi při instalaci čerstvého systému K3B vůbec nenabídne a budu si ho muset opatřit z jiného zdroje. Při instalaci nových balíčků taky žádný problém nevidím. Prostě v testingu je kupa balíčků, které mají navzájem vyřešeny závislosti, takže s instalací těhle balíčků není problém. Problém může být, pokud mám např. K3B z doby, kdy ještě v testingu byl a vyžaduje nějakou knihovnu, která je v konfliktu s jinou (novější) knihovnou vyžadovanou ostatními balíčky v testingu. To ale u čisté instalace nehrozí.

Že nějaký balíček v testingu byl a teď tam není může být nepříjemné, ale chyba to určitě není. Při velkých změnách (jako byl tenhle přechod na nové C++ ABI) je občas nutné některé balíčky z testingu dočasně odstranit, aby nebrzdily ostatní balíčky. Např. na novém libqt3-mt, kdelibs3 a gcc 4.0 záviselo pár (hodně) set balíčků, které se snažily dostat do testingu. A několik balíčků (amarok, k3b, ...), které nebude možné ještě dlouho (např. kvůli RC bugům) upgradovat na novější verzi, závisí na starších verzích důležitých balíčků a brzdí tak celý přechod. Kdyby nebyly odstraněny z testingu, celý přechod by trval mnohem déle, protože by se tvořily další a další konflikty. Nebo by se muselo zakázat uploadování nových verzí některých balíků do unstablu, dokud se současné verze nepropracují do testingu. Prostě zmatek. Dočasné odebrání některých problémových balíčků bylo IMHO jediné možné řešení.

[Libor Klepac]

souhlasim, navic neni problem si z unstable stahnout zdrojaky prislusneho balicku (nebo balicek, pokud tam neni nejaky problem se zavislostmi) a prelozit si jej proti balickum z testingu

[MartinB]

Že v testingu není v současné době K3B je sice smutné
...
Prostě se mi při instalaci čerstvého systému K3B vůbec nenabídne
...

Ano, to trochu smutne je.
Ja vim, ze neni problem si to zkompilovat nebo cokoliv co je mi tu razeno. Zkuste se na to prosim divat z trochu jinyma ocima, tj. ne vyvojare linuxu, ale realne nasazeni v praxi.

Při instalaci nových balíčků taky žádný problém nevidím
...
Problém může být, pokud mám např. K3B z doby, kdy ještě v testingu byl a vyžaduje nějakou knihovnu, která je v konfliktu s jinou (novější) knihovnou vyžadovanou ostatními balíčky v testingu.

Ano, presne o tom mluvim a povazoval jsem tyto dve veci za totozny pripad, asi jsem se tedy nepresne vyjadril. Shodneme se tedy na tom, ze nektere balicky "normalni" cestou nejdou do ciste instalace vubec dostat a ve "stare" instalaci se muzu dostat do situace, kdy mohou byt skrze verze knihoven v podstate v konfliktu dva ruzne balicky, tj. (ted placam-vykonstruovany priklad) - budu chtit nainstalovat Gimp, jenomze se mi tim odinstaluje K3B, protoze zavisi na jine verzi knihoven.

Při velkých změnách (jako byl tenhle přechod na nové C++ ABI) je občas nutné některé balíčky z testingu dočasně odstranit, aby nebrzdily ostatní balíčky.
...
které nebude možné ještě dlouho upgradovat

Chapu technicke duvody, proc je to nutne a respektuji to. Jak uz jsem psal - cely problem tedy nakonec tkvi v mem nepochopeni filosofie verzovani Debianu, tohle jsem proste ocekaval v unstable.

Jeste jednou pro vsechny, kteri mi tu porad tvrdi, jak je hrozne jednoduche portovat balik z unstablu, vytvorit vlastni binarni balicek atd. atd. - ano je, ale s tim si proste muzu hrat doma, uz jsem to psal nekolikrat. V praxi to vypada tak, ze mam na vyreseni problemu nekolik minut a ja nemuzu resit, jestli jsem na tomhle konkretnim stroji uz backportoval tyhle knihovny z tamhlete distribuce a jestli se mi to zase nahodou netluce s necim jinym a jak to bude vypadat po "legalnim" upgrade nekdy priste, kdyz jsem tam ted narval nasilim neco, co tam vlastne nepatri ... potrebuji kompaktni distro, do ktereho nechci zasahovat "proti prirode" :o)
Tomu tedy odpovida pouze stable (a na zadny server uz nikdy nedam nic jineho).
A proc nemuzu provozovat na desktopech stable? Jak asi odpovim na porade v roce 2007 na otazku, proc maji vsichi moji uzivatele treba OpenOffice 1.9, kdyz uz je davno 3.1 a nemuzou tudiz delat X Y Z, je to pomale a ja nevim co? (samozrejme to trochu zvelicuju, dalsi stable bude driv a ooo se tak rychle vyvijet nebude ;)) A nejde jen OOo. Jasne, zase mi nekdo napise, jak je strasne jednoduche portovat do stablu vybrany balicky z jinych distribuci a ja uz mu nebudu odepisovat. Na desktop pro hromadne nasazeni pro mne proste prichazi v uvahu pouze distribuce, ktera oplyva tim genialnim a bezproblemym systemem spravy balicku a aktualizaci, jakou ma Debian stable, ale zaroven mi poskytne baliky novejsi, nez rekneme 2-3 mesice. (vim, ze bezproblemovost stablu je z casti zpusobena tim, ze se nemeni verze balicku, nepitvejme to - urcite vite, co jsem chtel rict)

[Libor Klepac]

ja to take chapu, ale pokud by slo o hromadne nasazeni, neni problem si udelat vlastni repository a pridat si ho do zdroju apt ;) , obcas take musim rekompilovat nejaky balicek, protoze defaultni vlastnosti se nam nehodi do "kramu", tak to pak nahraju do repository a je to

[MartinB]

Ano ano, dosel jsem nakonec k temuz. Diky vsem za jejich cas, povazuji to za vyresene.

[tomas84]

Jojo, taky jsem měl trochu problémy. Ad k3b - docela mě to vytočilo, ale alespoň jsem se naučil používat growisofs ... je to úplně jednoduché.

[Robert Krátký]

Ten přechod kdelibs byl na mailing listech avizovaný dost předem. Stačilo počkat s aktualizací, než bude zase všechno srovnáno - pak by upgrade proběhl bez potíží.

[MartinB]

Ano, upgradujete-li jen tak pro plezir, tak muzete pockat. Jestlize jste v situaci, ze par lidi v praci POTREBUJE doinstalovat nejaky kus software (balicek), ktery ale nelze jen "apt-get install balicek", protoze balicek uz neni dostupny (je nahrazen novou verzi), musim napred "apt-get update", cimz se dostavam do popisovane situace s rozbitymi zavislostmi a nektere balicky uz proste nenainstaluju a nektere nainstalovane se dokonce snazi odinstalovat. Tohle proste nemuzu pred sefem obhajit, ze musi mesic pockat a pak to mozna pujde.

[!]

musim napred "apt-get update",

nechces snad tvrdit, ze tento prikaz muze za zavislosti balicku

cimz se dostavam do popisovane situace s rozbitymi zavislostmi a nektere balicky uz proste nenainstaluju a nektere nainstalovane se dokonce snazi odinstalovat.

pokud ti vadi resit obcasne problemy se zavislostmi, tak nechapu proc nepouzivat stable. tve nadavani je trochu slaboduche. zrovna tak nechapu proc pouzivas pouze upgrade a ne dist-upgrade, takze ti problemy se zavislostmi patri...

[Robert Krátký]

pokud ti vadi resit obcasne problemy se zavislostmi, tak nechapu proc nepouzivat stable.

Přesně tak. Jde-li o instalaci v práci, na kterou spoléhá více uživatelů, není důvod používat verzi _testing_.

[MartinB]

Duvody bych urcite nasel, na toto jsem uz castecne odpovidal Vasemu predrecnikovi.
Pri volbe distribuce jsem vychazel z tohoto:
- stable - az 2 roky stare balicky, ale 100% funkcnost
- testing - relativne nove balicky, ale ne moc proverene, tzn. muze nastat problem napr. se stabilitou konkretniho balicku, s distribuci a zavislostmi by nemel byt problem
- unstable - nejnovejsi balicky, pracovni verze, ve ktere budou (reseny) i problemy s distribuci, tj. zavislosti atp.

Takze jsem celou tu filosofii spatne pochopil, testing bude trpet stejnymi problemy jako unstable, jen v mensi mire.

Ted konstruktivne pro ty, kteri maji na vec stejny pohled jako ja (tedy jen ja )
Situace je takovato:
- zadnou lepsi variantu pro desktopy jsem zatim nenasel (predem diky za tipy)
- tyto problemy s testingem jsou tedy naprosto legitimni a budou se vyskytovat i nadale
- nelze je resit na kazde stanici s kazdym uzivatelem
- jejich reseni neni technicky prilis slozite a nevyskytuji se prilis casto (jen pomalu mizi ;))
Je pro mne tedy jedinym rozumnym resenim zprovoznit deb server a smolit tam vlastni distribuci testingu, ktera se bude lisit pouze temi nekolika opravenymi chybami rocne. Vsichni klienti budou upgradovat z neho a ja se budu starat jen o jedinou funkcni distribuci.

Uvaha na zaver - tohle preci muselo davno nekoho napadnout (skoda, ze ne na debian.org) - jak procitam ta fora - kazdy si to lepi doma sam, nebezi uz nekde takovy projekt? Stoprocentne vymyslim vymyslene...

[tomas84]

Stačí počkat, až se problém vyřeší a až poté provést upgrade. Tyto problémy nejslou příliš časté. Ale není se čemu divit, že při přechodu z KDE 3.3 na KDE 3.4 se nějaké vyskytnou.

[MartinB]

Nejde prece o to, ze chci provest z dlouhe chvile upgrade (tam skutecne mohu pockat). Jde o cistou instalaci a o instalaci balicku, ktere jsou (s trochou nadsazky) vlastne v konfliktu s jinymi balicky, ale to uz jsem tu vsechno psal.

[MartinB]

musim napred "apt-get update",

nechces snad tvrdit, ze tento prikaz muze za zavislosti balicku

Nemam pocit, ze bych neco takoveho delal, nerozumim teto otazce.

pokud ti vadi resit obcasne problemy se zavislostmi, tak nechapu proc nepouzivat stable.

Protoze na stanicich se vetsinou stable proste pouzivat neda. Mozna ted, kdy od jeho vydani jeste neuplynula takova doba, ale uz treba za pul roku... Pri volbe distribuci jsem zkratka po dlouhem zkoumani dosel k zaveru, ze na server je nejlepsi volbou deb. stable a na stanice deb. testing. Kdo je dobrodruh a chce byt up-to-date, muze si hrat s unstable.

tve nadavani je trochu slaboduche

Volte slova, priteli. Snazim se vyresit nejaky problem a nikoho osobne neosocuji.

zrovna tak nechapu proc pouzivas pouze upgrade a ne dist-upgrade,

Protoze neupgraduji distribuci, neprechazim ze stable na testing, ale jen v ramci testingu chci cerstvejsi balicky. Alespon tak jsem (nejspis tedy spatne) pochopil manualove stranky. Nebo se upgrade nema vubec pouzivat? A co kdyz pouziji aptitude? To spousti upgrade, nebo dist-upgrade?

takze ti problemy se zavislostmi patri...

Dekuji za pomoc, od toho to forum nakonec je.

[!]

musim napred "apt-get update",

nechces snad tvrdit, ze tento prikaz muze za zavislosti balicku

Nemam pocit, ze bych neco takoveho delal, nerozumim teto otazce.

treba proto aby si apt-get nacetl aktualni seznam dostupnych balicku

Protoze na stanicich se vetsinou stable proste pouzivat neda. Mozna ted, kdy od jeho vydani jeste neuplynula takova doba, ale uz treba za pul roku...

Nechapu proc by se nemel dat pouzit. Ja mam sice unstable, ale proc? Protoze mam dobry pocit ze muzu rict, ze jej mam, ale ne ze by to bylo potrebne...

zrovna tak nechapu proc pouzivas pouze upgrade a ne dist-upgrade,

Protoze neupgraduji distribuci, neprechazim ze stable na testing, ale jen v ramci testingu chci cerstvejsi balicky. Alespon tak jsem (nejspis tedy spatne) pochopil manualove stranky. Nebo se upgrade nema vubec pouzivat? A co kdyz pouziji aptitude? To spousti upgrade, nebo dist-upgrade?

upgrade - ti upgraduje pouze balicky co mas v systemu, ale neresi nove zavislosti tech upgradovanych balicku

dist-upgrade - upgraduje to co mas v systemu i s jejich treba nove vzniklymi zavislostmi

ale tohle vsechno mas pekne popsane v man apt-get, takze staci umet cist

Dekuji za pomoc, od toho to forum nakonec je.

neni zac :P