64 bit, 32 bit

Debian GNU/Linux

Röviden: a 64 bites Debianomra ma reggel Skype-ot tettem, és ehhez 32 bites csomagok kellettek. Szóval ma reggel óta van az i386-os architektúra is engedélyezve.

Miközben egy xbox360 kontrollerrel szórakoztam, az tűnt fel, hogy a 64 bites xboxdrv csomagot simán fel tudtam tenni, de az xboxdrv:i386 csomagot alapból nem, mert ütközött.

Függ (recommends) a python-dbus:i386 csomagtól, ami viszont ütközik a python-dbus csomaggal.

Na most ez a kérdésem: ilyen esetben mi az általános megoldás? Egyáltalán - hogyan ütközhet a kettő egymással? Hogy van Linux alatt megoldva a 32 és 64 bites cuccok együttélése? Feltételeztem volna, hogy vagy más nevű könyvtárban, teljesen más path alatt, vagy egymás mellett, de más néven léteznének az azonos csomag különböző változataiból érkező fájlok. Illetve persze a közös rész meg architektúrafüggetlen csomagból jön.

Pl. libc6 és libc6:i386 egyszerre fel van telepítve, nem ütköznek össze.

Ezt várnám a többi csomagtól is.

  • 8340 megtekintés

( NevemTeve | 2013. 10. 22., k – 10:19 )

Az ember sok mindent várna, ami nem teljesül... 'Normálisan' van neked pl /usr/lib és /usr/lib64 könyvtárad (kifinomultabb distróknak: /usr/lib/i386-linux-gnu/ és /usr/lib/x86_64-linux-gnu/), de pl a pthyonnak csak olyanja van, hogy /usr/lib/pyshared/pythonversion/*.so

( uid_6201 v | 2013. 10. 22., k – 11:06 )

Látatlanban esélyesnek tűnik, hogy az xbox360 CPU-ja olyan 3 magos PowerPC, amely csak 64 bites módot tud. Így a disztribúciók sem kínlódtak ennél az eszköznél a "/usr/lib/i386-linux-gnu/"-hoz hasonló /usr/lib/ppc32-linux-gnu/ könyvtárba helyezett lib-ekkel. Ugyanakkor furcsák a fentiek tükrében a 32 bites csomagok és a ":i386" végződés.

Légyszíves másold ide az xbox360-ban kiadott alábbi két parancs által kiírt szöveget.

cat /proc/cpuinfo
dmesg

( vl v | 2013. 10. 22., k – 11:59 )

Szerintem alapvetően ott van a koncepciód elrontva, hogy azokból a dolgokból tud lenni csak fent két verzió, aminél ez elkerülhetetlen volt (mert azoknál csinálták meg, a többibe nem fektették bele az energiát, mert minek).
Tipikusan ezek a könyvtárak, mert azokat a 32-bites és a 64-bites alkalmazásoknak egyaránt kell tudniuk használni. Azonban egy sima alkalmazásból nincs értelme felrakni mind a kettőt, továbbá nem is felhasználóbarát, hogy két bin könyvtár legyen.
Egy drivernél pláne nincs értelme a dolognak, hiszen csak egy kernel futhat, a 64-bites kernelbe meg nem fogod a 32-bites modulokat betölteni, tehát csak a kernelhez passzoló drivernek van értelme.

A csomag, amit telepíteni próbáltam, az egy userspace program.
Azért gondoltam, hogy 32 bites jó lenne, mert a Steam szintén 32 bites.

Maga a driver feltelepíthető, python-dbus nélkül.

A recommended python-dbus:i386 viszont összeakad a valami más csomag által megkövetelt python-dbusszal.

Fogalmam sincs, hogy a te koncepciód szerint a python-dbus könyvtárnak számít-e vagy sima alkalmazásnak, de ha egy 64 bites alkalmazás a python-dbust kéri, egy 32 bites alkalmazás meg a python-dbus:i386-ot és ez a kettő egyszerre nem mehet fel, akkor szerintem gond van.
Vagy python-dbus:all csomagtól kéne mindegyiküknek függenie (ha mondjuk architektúrafüggetlen python scriptekből áll a csomag), vagy meg kellene oldania a csomag készítőjének, hogy mindkettő verzió felmehessen.
Szerintem.

Persze nem néztem utána, nem tudom, hogy hogyan válnak el a 32 és a 64 bites csomagok egymástól és nem tudom, hogy ez a konkrét csomag mit csinál vagy mit nem, ami miatt nem telepíthető.

Azért kérdeztem, mert azt hittem, erre van valami holt egyszerű válasz.

Nem értem igazán, ez miért kérdés, vagy hogy a válasz hogyan segít.

Természetesen néhány különböző verziójú bináris pythonra lehet szükség, a különféle csomagok függősége miatt.
Hány lehet egyszerre? Fogalmam sincs, hogy van-e bármilyen korlát erre nézve. Nem hiszem, hogy 2 különböző verziónál többet láttam volna eddig.

Ha az a kérdés lényege, hogy az execve(2) korlátozva van-e olyan binárisokra, amik ugyanolyanok, mint amiben az execve-t hívod, akkor nem hiszem, hogy ez így lenne, ugyanis (majdnem*) minden futó program (közvetve vagy közvetlenül) az init(8)-ből származik, tehát azzal azonos típusú kellene legyen.

*: igazából, a kernel másképp is indít programokat, lásd pl /proc/sys/kernel/hotplug

Szerény számításaim szerint semmi szükség arra, hogy legyen 32-bites Python és 64-bites Python is ugyanazon a gépen...

Sajnos lehet rá szükség. Az más tészta, hogy szerintem egyetlen disztribúció sem ad ehhez segítséget.

Hogy miért lehet szükség rá? A 32-bites Pythonba csak 32-bites modulokat lehet rakni, azok pedig csak 32-bites lib.so-kat tudnak használni. Ugyanígy, a 64-bites Pythonba csak 64-bites modulokat lehet rakni, és csak 64-bites lib.so-kat tudnak használni.
Ha van egy külső csomag, ami forrásban nem áll rendelkezésre, és van neki egy lib.so-ja csak 32 vagy csak 64-bites verzióban, hozzá pedig egy Python modul, amit szeretnél használni, akkor a lib.so határozza meg, hogy 32 vagy 64-bites modult és Pythont kell-e használnod. Mondjuk egy régi, 32-bites Oracle-höz a hozzávaló kliens lib 32-bites lesz, azt pedig csak egy 32-bites Pythonba tudod begyógyítani.
A történet zsákutcába is tud fordulni, ha egyazon programban szeretnél két külső libet használni, és az egyik csak 32-bites verzióban áll rendelkezésre, a másik meg csak 64-bitesben, mert ezek egy binárisban sose fognak működni.

( gabor2 | 2013. 10. 23., sze – 21:59 )

Nekem par hete tonkre vagta a fejlesztoi kornyezetemet, hogy felraktam egy 32bites deb csomagot ami aztan elkezdett telepites kozben par 64bites csomagot letorolni, valami conflict volt azt irta. Ekkor viszont nem tudtam a sw-unket forditani, tehat letoroltem a telepitett 32bites csomagot de mar soha nem allt vissza az eredeti allapot.
Ha jol emlekszem a libcurl hianyzott neki. Azota nem rakok fel 32bites csomagokat. :)

Nekem ugy tunt, hogy ez a 32bites csomag a 64bites gepen egy picit ganyolas.