Úprava existující distribuce - Řešení závislostí (diskuse)

[j]

Určitě jsi to hodil do googlu, takže tohle tedy z nějakého důvodu nefunguje. Jen aby to někdo omylem nedoporučil.

https://stackoverflow.com/questions/6242761/determine-direct-shared-object-dependencies-of-a-linux-binary

[JS1]

Ugh, doufam, ze ti napise nekdo, kdo Linux opravdu dela, lepsi odpoved v podobnem duchu (ja jsem uz leta je BFU). Ja mam pocit, ze to co volis neni uplne idealni cesta, ale zalezi, jake jsou tvoje cile. Slackware jsou v podstate 90. leta Linuxu, coz je z nostalgie pekne, ale pokud to budes chtit pouzivat, budes s tim mit nejspis spoustu starosti. IMHO, moderni Linux se tim nenaucis, ale pokud chces nostalgicky zavzpominat, tak je to super plan.

Stejne tak neni z tveho prispevku jasne, na co chces pouzit make. Myslis na reseni zavislosti mezi balicky? Na to IMHO urcene neni a nebude. Make ma vyznam jako primitivni buildovaci system (a zase, neni to nic proti make, na co to staci to staci), ale na zavislosti mezi balicky existuji specializovane nastroje, jako apt a yum.

Obavam se, ze si uplne neuvedomujes, do ceho jdes. Budes si psat na kolene vlastni system zavislosti, a pro moderni systemy je to netrivialni uloha. Zase, muze to byt zajimava historicka exkurze, ale pokud je cilem neco jineho, tak mozna budes zklamany.

[JS1]

Co jsem chtel vyjadrit a vypadlo - pises "upravit k obrazu svemu", to naznacuje, ze ten system chces pak nejak prakticky pouzivat. A toho se prave obavam, protoze si myslim, ze volis zbytecne trnitou cestu. Moderni aplikace pro Linux proste predpokladaji spousta infrastruktury, kterou si chces sam na kolene vytvaret a upravovat. Bude to asi dost netrivialni prace pro jednoho cloveka, ktera uz navic byla proslapnuta v jinych distribucich.

[Jack Hokus]

Dobrý den,

nejdřív, děkuju za odpověď. Je vidět, že víte o čem píšete.Ano, Slackware je tak trochu relikt, ale právě proto jsem si ho vybral.

V tuto chvíli toho moc neumím a tomu jsou úměrné i mé cíle. Chci si zkompilovat Novější Firefox, Přítomná verze je 68.8.0esr. Chtěl bych 7O. Starší verze nezvládá některá videa na YT a ty na FB vůbec. Krom toho Openscad.

Pokud máte na mysli tu zmínku o makefilu. Tak mne k ní přivedlo to, bych si chtěl někam uložit parametry použité při kompilaci, abych nemusel při aktualizaci zadávat vše znova. Tak jsem to zamýšlel.

[rastos]

Starší verze nezvládá některá videa na YT a ty na FB vůbec

.

Napr.?

[Bherzet]

Pokud máte na mysli tu zmínku o makefilu. Tak mne k ní přivedlo to, bych si chtěl někam uložit parametry použité při kompilaci, abych nemusel při aktualizaci zadávat vše znova.

Makefile, nebo jiné obdobné build skripty, už budou součástí zdrojových kódů daného projektu. Jejich úkolem je jednak šetřit čas, tj. kompilovat jen soubory, které se od posledně změnily nebo zatím zkompilované vůbec nebyly, a jednak jednotlivé operace provést ve správném pořadí.

Makefile obsahuje, velmi zjednodušeně řečeno, seznam návodů (receptů), jak vyrobit nějaké soubory. Pokud vytvoření těchto souborů samo o sobě závisí na jiných souborech, bude tato závislost explicitně uvedena. Make se pak postará o to, aby se zbytečně nevytvářely soubory, které už existují, a naopak nic nechybělo.

Pro úplně nejtriviálnější příklad, za který mi tu jistě někdo urve hlavu, si můžeme ukázat, jak by vypadal Makefile pro sestavení souboru c z nějakých dílčích souborů a a b:

.RECIPEPREFIX = >

c: a b
> cat a b > c

a:
> echo "a" > a

b:
> echo "b" > b

clean:
> rm a b c

.PHONY: clean

Když sputíte make, v (aktuálním) pracovním adresáři se vytvoří soubory a, b a c. Můžete si zkoušet jednotlivé soubory mazat a sledovat, jak se Make při opakovaném volání chová. Pokud chybí jen soubor c, vytvoří jej ze souborů a a b. Pokud ale jeden z nich chybí, tak ještě prvně vytvoří ty.

Tak tolik k velmi stručnému úvodu do Make. A teď k té podstatné pointě: podle mě to k účelu, který jste popsal, vůbec nepotřebujete. Pokud při kompilaci potřebujete předávat nějaké parametry a chcete si je někam „zapsat“, bohatě k tomuto účelu postačí obyčejný shellovský skript, který bude volat už existující build systém.

Pro Make zde nevidím uplatnění.

[Jack Hokus]

Dobrý večer,

díky moc, to jsem nepochopil.

Petr

[Bherzet]

Ten můj komentář, nebo předtím jak funguje Make?

[debian+]

Příloha:

• make_ako_na_to.tar (30720 bytů)

Tu mas ukazku programu a preklad pre make.

Ak zmenis jednu hlasku, nebude sa prekladat vsetko, len to co sa zmenilo.

[rastos]

Ná základe čoho to píšeš?

Slackware síce možno pochádza z minulého tisícročia, ale rozhodne to nie je jeho jediné miesto. Používať sa do dá úplne bez problémov. Ak nerátam to, že a) nemáš k dispozícii 30k balíkov out of the box b) rady typu "sudo apt-get install xyz" sú na figu. Na druhej strane množstvo software-u bez problémov dokážeš skompilovať (ak ho nechceš alebo nenájdeš na SlackBuilds). Tomu systému sa dá rozumieť. Nebude ti stáť v ceste, keď chceš niečo neobvyklé. A keď sa niečo pokašle, tak sa dá dopátrať čo a kde.

A čo je to "moderný linux"? SystemD? Snap a flatpack? Pche. To si môžeš nechať.

[johnyK]

ja si myslim, ze JS1 to popsal docela presne. Jsou 2 alternativy:

- autor si chce hrat, ucit, rozsirovat obzory

- autor by mel rad system, ktery ho bude v profesionalni praci podporovat a neomezovat

Pro tu prvni variantu mu i JS1 potvrdil, ze to je dobra volba. To si myslim take.

V tom druhem pripade jsem stejnho nazoru jako JS1 - vpodstate ve svem druhem komentari upozornuje na ten zasadni fakt -> delbu prace.

Ta delba prace je to, bez ceho se v profesionalni situaci nikdo z nas neobejde. Kdyz budu pouzivat Slackware a budu chtit zakaznikovi nainstalovat Kerio-Mail-server, tak musim z tech rpm-balicku nejdriv udelat nejake ty .tgz pro Slackware. Jde to a sami jsem to ve firme take tak delali. Ale to neni vlastne nase uloha - mu musime podporovat zakaznika v oblasti provozu mailu a od zbytku nas musi odstinit ta delba prace.

[debian+]

Predtym nez zacnes riesit zavislosti, nauc sa, minimalne teoreticky, prekladat program staticky a dynamicky.

A ako zistis ktory program ake kniznicce potrebujes? Bud zo zdrojakov (Makefile config alebo v kode kuknutie ake kniznice includuje/pouziva). A u realnych uz nainstalovanych program v systeme to zistis napriklad:

ldd /bin/bash
ldd /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
which `ldd geany`

Pozri aj prikazy:

whereis
pkg-config --list-all

Cital si knihu Linux: Dokumentační projekt (v3 CS) alebo Linux: Dokumentační projekt (v4 CS, iba text)? Ak nie, pozri si ich.

[❗Červivý Hřib krade❗]

ale benák řikal žeje to jakoby nejvíc nejzbytečnější knížka tamten linux dokumentační projekt :O :O hele :O :O :O :O

[billgates]

Pravdu ma samozrejme debian+, lebo je Slovak. Benak keca blbosti, ako obvykle. Ved sa staci pozriet na jeho web, kde ma nejake .NET, java, DB2, eclipse a podobne sracky. Co cakat od takeho cloveka? Nic rozumne!

[debian+]

Este sa zistit z vypisu spustene ./configure.

[johnyK]

Prozatím jsem našel tento odkaz

na tom odkazu je nejzajimavejsi osoba odkazovaneho autora. Pan Kersleger ten linux v Cechach co vim 'zavadel' a jestli bych si neco mohl prat, tak nekdy clanek nebo rozhovor s nim, jak to tenkrat bylo.

[Petr]

Možná bys místo ze Slackware mohl vyjít z NixOS

[debian+]

To by mohol rovno z Debianu

[Petr]

Tak samo, byl by to posun od Slackware směrem k Debianu, ale do Debianu ještě cesta daleká, předpokládám, že chce i tvořit svoje balíčky. Nebo by mohl začít stavět na LFS s Nix, těch možností je, ať už s Nix(OS) nebo bez.

[Jack Hokus]

Dobrý večer,

zajímavé, podívám se na to.

Děkuji

[divny host]

Tak Nix jako správce balíčků by měl fungovat i na Slacku, netřeba kvůli tomu měnit distro.

Na druhou stranu funguje dost odlišně od ostatních package managerů a s tím je spojená dost nepříjemná učící křivka, takže pokud je cílem blíže pochopit jak fungují linuxová distra tak nevím jestli bych ho doporučil (a to říkám jako někdo kdo NixOS používá a nevidí cestu zpátky).

[Vantomas]

Před pátnácti lety mi v tomhle všem dalo největší školu Gentoo. A snaha, že když už jsem si něco rozbil a dostal se do dependency-hell, to zkusit opravit a ne použít mkfs.ext3 a začít odznova....

[Odin1918]

Zavislosti se resi lecenim a ne upravou existujici distribuce. Pokud i nadale chces upravovat, upravuj debian a ne nejaky relikt, ktery je cool zhruba jako socialismus riznuty ekologii.

[debian+]

Dostuduj si historia. Co sa tyka aktivneho pouzivania - tak Debian je hned 2. najdlhsi pouzivana linuxova distribucia, po distribucii Slackware.

Slackwarovsky spravca balickov neriesi zavistlosti medzi balikmi.

[Odin1918]

Nemusim nic dostudovavat bratre. Sam potvrzujes svym prispevkem, ze debiab novejsi a schopnejsi je.

[debian+]

na disku mám nainstalovaný Slackware a rád bych si ho upravil k obrazu svému.

Aky mas problem? Co chces zmenit voci defaulnej distribucii? Vyber programov? Vzhlad aplikacii? Defaulne nastavenia programov? Alebo co konkrtne? Ake mas osobne pohnutky? Niekedy staci na aplikovanie zmien spustit skript. Niekedy vytvorit balicek. Niekedy vytvarat odvodenu distribuciu. Staci prve kroky a ciele. Ake riesis problemy?

To co pises, je len zatial teoria bez praxe. To je ako operovat v hre versus operovat nazivo.

---

Každý dobrý program začíná tím, že řeší potíže samotného programátora.

Zdroj: Katedrála a tržiště

---

To je jasné, ale jak zjistím, které stávající knihovny je třeba aktualizovat?

Tieto informacie musis zistit (pri preklade si poznacit), alebo ich mat (zistit zavistlosti z existujucich spravcov balikov).

[debian+]

Hlavní věc, kterou nevím, je to, že když chci nainstalovat novější verzi programu, tak ten vyžaduje novější verze knihoven. To je jasné, ale jak zjistím, které stávající knihovny je třeba aktualizovat?

Su 2 typy aktualizacii:

• bezpecnostne - vtedy treba aktualizovat co najskor (napr. Přetečení zásobníku)
• funkcne - tie treba dobre otestvovat a patria k tommu napr. pridanie alebo rozsirenie existujucich funkci

[V.]

Pokud používá program nějaké knihovny, vypíšete si to přes ldd na celou cestu binárky.
Viz např. wikipedie - ldd.

[otula]

K těm potřebným závislostem si dovolím ti poradit zcela nesystémově. Co takhle využít dostupné informace odjinud? Třeba z Archu systémové balíčky a AUR nebo z Gentoo. Ale udržovat to ručně si nedokážu pro normální používání počítače představit. Každá závislost má své závislosti, aktualizací některé závislosti může přestat fungovat zase jiný program...

[Jack Hokus]

Dobrý den,

Děkuju za typ. Přemýšlel jsem o tom.

Petr

[.]

Ty jsi ten, jak nepochopil ani řádek shell skriptu? Bez urážky, ale máš před sebou tak rok, než se do něčeho takového můžeš pustit. A to jen pokud tu dobu budeš hódně studovat.

[Jack Hokus]

Dobrý den,

Ano, jsem to já a ano, s tím rokem počítám.

PS: Nic z uvedeného není míněno ironicky

[prqek]

To je jasné, ale jak zjistím, které stávající knihovny je třeba aktualizovat?

To ví (v ideálním světě) autor toho programu. Neexistuje žádná obecná (samozřejmě, pokud jde o nějakou velkou změnu, tak to jde) rozumná metoda, jak to spolehlivě zjistit z toho programu samotného. Autor by to měl mít otestované s určitými verzemi a tuhle informaci předá správci daného balíčku. Ten ji tam pak zakomponuje. Proto se takty ty balíčkovací systémy používají - abys nad těma závislostma nemusel spekulovat sám.