jak zabránit instalaci balíků arch. i586 do 64bit Opensuse

15.3.2009 10:45 | | poslední úprava: 15.3.2009 11:01

Jednou z kritizovaných vlastností balíčkovacího systému Opensuse je ochota instalovat i586 balíčky do 64bit systému. To při některých veletočích s balíčky vede k tomu, že se správce balíků snaží zcela nesmyslně downgradovat půlku systému z x86-64 na i586. Například distribuce postavené na Debianu nakládají s i586 balíčky na 64bit systémech jako s cizí architekturou. Pokud chcete docílit stejného chování i na 64bit Opensuse, není nic jednoduššího, než architekturu i586 zakázat. Podrobný popis celé problématiky popisuje Libzypp/Locksfile wiki.

Informace o takovýchto blokacích se nacházejí v souboru:

/etc/zypp/locks

Ve svém oblíbeném editoru tedy otevřeme tento soubor:

sudo nano /etc/zypp/locks

A na konec souboru vložíme řádek:

solvable_arch: i586

Od této chvíle jsou všechny i586 balíky uzamčeny. V Yastu se to například projeví ikonkou "nikdy neinstalovat"        

Komentáře

[přítel :-P]

Pokud chcete docílit stejného chování i na 64bit Opensuse, není nic jednoduššího, než...

raději bych léčil příčiny.

# rm -rf /

[rx88]

tomu nerozumím. Jako že bude tato volba výchozí?

V debianu taky můžu instalovat i586 balíky do amd64 systému. Jen to není ve výchozím stavu povoleno.

[miso]

       --no-preserve-root
              do not treat `/' specially

       --preserve-root
              do not remove `/' (default)
 

[Scarabeus IV]

Na to je lek typu rm -rf /*

[miso]

Len som chcel ukazat, ze

rm -rf /

defaultne nefunguje a vela ludi to nevie. Ja som potreboval VirtualBox, aby som si to overil, dovtedy som proste neveril (a man som cital)

 

[Ladicek]

A já myslel, že zásadní výhodou zypperu je, že se nemusí ručně editovat konfiguráky, protože běžný u64ivatel

[Käyttäjä 11133]

On běžný uživatel (tm) používá zypper, nebo se dokonce stará o to, jestli je balíček 64bit, nebo 32bit? Já myslel, že běžný uživatel (tm) ani neví co je to architektura.

[pushkin]

Můžu se zeptat, konkrétně u jakého balíčku se ti tohle stalo? Osobně jsem instaloval poměrně dost i586 (případně i386, i486) balíčků, a pouze se doplnilo několik knihoven pro 32bit kompatibilitu (ty s příponou -32bit v názvu), ale nikdy se Yast nesnažil o "dvaatřicetibitizaci" systému.

[rx88]

typicky v případech, kdy člověk experimentuje s novými věcmi zasahující mnoho balíků. Pak má balíčkovač tendenci místo odinstalace nesplněných závislostí řešit problém změnou architektury.  Naposledy při downgradu KDE  4.2 na 4.1 (když bylo KDE 4.2 ještě nepoužitelné).

Osobně bych se nebránil tomu, kdyby balíky typu Wine.i586 nebo W32codecs.i586 dostaly své bratřičky Wine-32bit.x86-64 a W32codecs-32bit.x86-64 a člově nemusel to 64bit systému tyto vůbec instalovat. Přece jenom v principu k tomu důvod není.

[pushkin]

Co se týče KDE4, to je většinou problém repozitáře, kde poměrně často některé balíčky chybějí, tady nelze doporučit nic lepšího, než u každého podobného problému ohlídat verzi balíčku ručně. Pak je jasné, že když nejsou dostupné třeba kdelibs v x86_64, pak je třeba je nahradit za jiné (dostupné jsou třeba právě i586) a tím pádem je třeba prakticky celý systém závislostí KDE nahradit za 32bit.

Jinak k tomu Wine a W32codecs. To je poměrně tenký led, protože AFAIK funkční Wine lze zkompilovat v současné době pouze jako i586, při pokusu o kompilaci jako x86_64 se sice zkompiluje, ale neprojde řadou testů. Proto wine...i586.rpm. Btw.: pokud vím, tak zrovna Wine nemá žádnou i586 závislost.

W32codecs jsou pak binární soubory z Windows, které jsou 32bitové, nelze je tedy jako x86_64 označit. Navíc třeba v kombinaci s mplayer x86_64 jsou ti k ničemu, protože 64bit mplayer je jednak neumí číst a jednak už většinu formátů obsažených ve w32codecs dekóduje nativně. Osobně tento balíček (w32codecs) osobně považuji za přežitek, který není potřeba v současné době vůbec instalovat.

[rx88]

moment. Tady mi musíte něco vysvětlit. Je tato nemožnost dána kompilací? Já měl za to, že to lze nastavit libovolně při dodržení určitých pravidel. Takový debian má w32 codecs pro 32bit systém a w64 codecs pro 64bit systém. Přitom uvnintř budou tyto balíčky hádám stejné. Oba sjou nepochybně 32bit, ale díky tomu se nemíchají i586 a AMD64 balíky. opensuse má taky spoustu balíků -32bit.x86-64. V čem je tedy problém? podle mě je to jen nedostatek značení, a dodělání 32bit balíků i ve verzích pro 64bit architekturu (32bit balík s nálepkou x86-64)

[pushkin]

Tak hluboce do balení RPM nevidím, ale pochopil jsem to tak, že to, co je 32bit binárka, nelze (nebo lze, ale třeba "to není z etických důvodů vhodné") označit jako x86_64. Ty -32bit x86_64 balíky jsou balíky zajišťující kompatibilitu s i386 (neptejte se mě jak), nejde přímo o 32bit balíčky (viz třeba kdelibs3, jejichž neinstalované velikosti velikosti jsou:
kdelibs3-3.5.10-42.1.i586.rpm 2009-Feb-16 02:34:12 14.8M
kdelibs3-3.5.10-42.1.x86_64.rpm 2009-Feb-16 03:01:59 14.8M
kdelibs3-32bit-3.5.10-42.1.x86_64.rpm 2009-Feb-16 02:34:14 7.5M,
bráno odtud). kdelibs3-32bit-3.5.10-42.1.x86_64.rpm se tedy určitě podstatně liší od kdelibs3-3.5.10-42.1.i586.rpm, nejde tedy určitě o 32bit balíček (alespoň ne plnohodnotný, i když tak funguje).

Btw.: ad w32codecs vs. w64codecs. Jeden balík má velikost 33MB, druhý 492kB, určitě tedy nebudou mít shodný obsah.

[rx88]

A. Tak v tom debianu jsem asi použil blbý příklad. Pravdou ale je nějak takto to skutečně funguje. Viz:

http://packages.medibuntu.org/intrepid/w64codecs.html

V případě kdelibs3 bych hádal, že kdelibs-32bit obsahuje to nutné 32bit minimum k 64bitovému kdelibs3. Tedy  že pouze část balíku kdelibs3 je nutná také ve 32bit verzi. V případě Wine je balík třeba celý, proto nevidím důvod, proč by nemohl existovat Wine-32bit.x86-64.rpm

[pushkin]

Tradice

[Ilfirin]

Stává se to, když chce čék odinstalovat nějakou knihovnu, na které jsou závislé některé nainstalované aplikace. Jedno z řešení je neodinstalovat ty aplikace, ale najít jiný zdroj knihovny... i586. To pak přináší i změnu architektur těch aplikací a závislostma to přeroste ve změnu půlky distribuce.

[rx88]

No tak teď se tohoto nešvaru zbavíme