Dotaz: Gentoo, ebuild, zavislost na jednom z nekolika balicku

[Gilhad]

Potrebuju pro Gentoo udelat nejake balicky a nevim, jak vyresit zavislosti.

Hlavni program PROG potrebuje mit nainstalovany prave jeden z balicku LIB1, LIB2, LIB3, ... LIB10,LIB11,...

Je potreba aby byl nainstalovany prave jeden z nich, ale hlavnimu programu nezalezi na tom, ktery to je (vyber se bude zarizovat jinak)

To by slo snad zaridit pomoci RDEPEND="|| (LIB1 LIB2 LIB3)"

Zaroven nesmi byt nainstalovany dva z LIB1...LIBxy (maji spoustu "spolecnych" souboru, ktere se obsahem lisi).

To by (pro LIB2) asi zaridilo RDEPEND="!LIB1 !LIB3"

Predem nevim, kolik tech LIBxy bude, vim ze budou casem pribyvat. Proto bych se rad vyhnul nutnosti pri pridani LIBxy prepisovat ebuild PROG (pro pridani te LIB) a prepisovat vsechny ebuildy vsech ostatnich LIB (aby se navzajem vylucovaly). Taky mi prijde, ze by prece mela byt nejaka jednodssi cesta, jak tohle zapsat, nez milionkrat opakovat stejne seznamy, jen s vynechanim jednoho prvku.

(Predstavuju si neco jako

PROG: RDEPEND="MyLib"

LIB1: PROVIDE_EXCLUSIVE="MyLib"

LIB2: PROVIDE_EXCLUSIVE="Mylib"

.... )

Postup instalace je povinne dan, ze admin nejdriv nainstaluje jednu z LIBxy, potom nainstaluje PROG (potom obcas zupdatuje cely world). Instalace PROG bez predchozi instalace LIBxy nedava smysl a musi selhat chybou. Taktez nedava smysl, aby si system sam vylosoval nejakou LIBxy, pokud neni zadna explicitne nainstalovana.

Nevite nekdo, jak toto nejak jednoduse a prehledne zabezpecit? (V tuto chvili je tech LIB vic nez 10 a ceka se ze zacnou pribyvat rychleji)

Odpovědi

[rADOn]

Tohle se afaik obyvkle resi tak ze se zridi virtualni balik. Treba virtual/mysql je RDEPEND="|| ( =dev-db/mysql =dev-db/mariadb)". Programy ktery chteji "nejakou" mysql si daji zavislost na virtual a neresi na koho to padne.

[Semo]

Co ale riesi asi iba 1/3 pozadovaneho chovania.

[petr_p]

Řešíte problém na špatném místě. Že dva balíčky nemohou být nainstalovány najednou, se píše do nich. Nemá smysl to psát jinam, protože uživatel se může rozhodnout nainstalovat právě jen tyto dva vylučující se balíky.

Netvrdím, že váš požadavek na nějakou podporu od PMS není legitimní, ale řekl bych, že podle postup instalace je povinne dan, se snažíte zneužít balíčkovací systém na něco, k čemu určen není, nebo nějak, jak se používat nemá.

Přehled konfliktů můžete schovat do eclassy a ze všech balíků ji použít. Nevím ale, jestli lze *DEPEND proměnné generovat dynamicky.

[Gilhad]

"postup instalace je povinne dan" jsem myslel, ze ja jakozto tvurce systemu urcuju, jak ho maji technici instalovat (technici nic nerozhoduji, proste provedou par instrukci a pockaji az to dobehne). Ale protoze clovek je chybujici, tak se snazim co nejvic moznych chyb odchytit predem nejakym rozumnym zpusobem.

Nema zadny rozumny smysl instalovat dva ruzne baliky LIBxy, protoze delaji totez, jen pro ruzny HW (a v danem nasazeni neni mozne, aby jeden stroj mel naraz dva typy HW, nebo aby se delal nejaky "univerzalni" stroj)

Chtel jsem dat do kazdeho LIBxy *DEPEND, ktery vylouci vsechny ostatni LIBxy, ale znamena to pri kazdem pridani knihovny prepsat ty dependy ve vsech stavajicich knihovnach, coz mi prijde takove silne neelegantni.

Pak je tu samozrejme moznost to neresit a nechat to spadnout pri instalaci na konflikt souboru, ale to je takove trochu humpolacke a spadne to az celkem pozde - vic by se mi libilo, kdyby se to odmitlo naistalovat uz ve chvili vypoctu zavislosti.

Jinak jde o dost specialni system na zakazku a tyto knihovny/program se nikam jinam sirit nebudou a uzivatele si s nima vlastne nemaji co hrat a ani nemaji zajem nic resit - z jejich pohledu jde o cernou krabicku, ktere nekde sedi, zere proud a dela co ma, nic vic. To jen ja si chci (sobe a technikum) usnadnit instalace a updaty.

[petr_p]

Díval jsem se do PMS, a existuje exactly-one-of skupina, která se definuje přes dvě stříšky. Ale je možná ji použít jen v REQUIRED_USE. Takže by se dali takto omezit USE flagy a jejich přítomnost pak převést na závislosti.

[rADOn]

ja jakozto tvurce systemu urcuju, jak ho maji technici instalovat (technici nic nerozhoduji, proste provedou par instrukci a pockaji az to dobehne)

To je všechno hezký a rozumný… a úplně šílený. Filozofie "root je debil kterého je nutno vodit za ručičku" je úplný opak toho jak funguje gentoo, pokud máš potřebu ho tímhle způsobem znásilňovat tak se nediv že ti to zrovna neulehčuje

Určitě by se na to dala napsat eclass, podívej se třeba na ebuild apače který takhle vybírá mpm moduly. Ale bude to kapku složitější. Na to co popisuješ by stačilo udělat si sadu meta balíků které budou záviset na společné části a knihovně pro ten který hardware, to zvládne jednoduchý makefile. Tvoje pologramotná obsluha by instalovala pouze jeden balík.

[Gilhad]

Ono je to trosku jinak - root jsem predevsim ja, ale mam spravovat par stovek takrka identickych boxu, tak se snazim to co nejvic zautomatizovat. Cim vic toho udela automatika, tim min mam prace a tim min chyb ci opomenuti udelam.

Cely tento problem je jen malou casti celeho reseni a snazim se to dotahnout do stavu, kdy podle HW nainstaluju spravny balik, pak nainstaluju super_mega_system_all balik a vse ostatni se vytahne jako zavislosti. Na konec spustim super_mega_konfigurace.sh a vse se spravne nastavi na defaulty (pokud jsem nekde nerekl vyslovne jinak)

Kluci technici se predevsim staraji o vymenu vadnych kusu (oblibene je vyhorely zdroj) a instalaci z image, ktere jim pripravim. Ale kdyby byl jednoduchy nastroj, jak obejit ty image, tak by to asi bylo lepsi. Jenze to uz musi byt hodne jednoduche a neprustrelne, aby s tim mohl pracovat i nekdo, kdo tomu prilis nerozumi.

Gentoo mi vyhovuje, protoze ho mam doma a pouzivam pri vyvoji, jim je zcela jedno, co tam bezi, tak mam proste mirror, kde je vzdy nejaka odzkousena zmrazena verze a boxy se synchronizuji vuci tomuto mirroru. Takze vetsinu doby maji vsechny stejne verze programu v nejakem konzistentnim stavu.

Dodavam to jako reseni jine firme (ktere patri ti technici) a leta nam to funguje velice dobre k oboustranne spokojenosti. (Pravda, jsou tam nejruznejsi zajimave artefakty, z nich cast jsem zdedil a cast vznikla podivnymi pozadavky zakaznika, ale postupne to ucesavam za chodu. Nicmene musim volit cestu pozvolne evoluce, protze to proste nejde naraz cele odstavit a spustit po case s novou zcela jinou verzi. Takze spoustu historickeho balastu jeste nejakou dobu potahnu).

Ti technici puvodne neumeli nic, ale maji snahu se ucit a chteji mit pristup k co nejvetsi funkcnosti, pokud jim ten pristup zvladnu udelat dost jednoduchy. Proste tato spoluprace ma svoje "specifika", ale rozhodne se obema stranam vyplaci i s nima.