Balíčkovací systémy aneb tisícprvní zamyšlení na toto téma (diskuse)

[Michal Vyskočil]

Takže jestli se nepletu, tak jsi vymyslel jednodušší verzi Zero Install ...

[regnarg]

Zero install se mi zdá, že staví na zcela odlišném principu...

[Lu-Tze]

Ta úvodní pasáž mě dost vyčerpala (btw měl jsem dojem, že si to cucáš z prstu), takže jsem to nedočetl tak do poloviny, ale nezdá se mi, že bys nějak řešil nebo mohl řešit bezpečnost - jak to bude s podepisováním balíčků? Při distribuovaném modelu se mi to zdá nemožné.

[regnarg]

To jsem zatím neřešil. Možná příště...

[lefty]

mno obávam se že balíčky se můžou distro od distra lišit, tím se řeší nutnost přizpůsobit se prostředí distribuce (gentoo to řeší patchováním originálního src staženého z internetu) - třeba že někdo používá /media zatímco někdo /mnt. v tom je skutečný problém balíčkovacích systémů - každá distribuce potřebuje vlastní sadu, což je dáno rozdílností distribucí. někteří lidé říkají, že by se distribuce měly "zrušit a sjednotit" - to by ale byl konec této (někdy svazující) svobody, kterou distribuce uživatelům dávají. já bych se problém snažil spíš řešit co nejvíce "standarty", které by musely distribuce splňovat (pak by jim byl vystaven třeba certifikát kompatability) a které by se snažily sjednotit hlavní rozdíly. to je takový kompromis, který bude zajišťovat co největší kompatabilitu při ponechání co největší svobody. pak by mohl být vytvořen "hlavní repozitář" (jako seznam balíků) a třeba část systému přenést na vývojáře (a internet - nemám rád přílišnou centralizaci), kteří budou sami vytvářet a registrovat balíky (no more package mainteiners !) ...

[regnarg]

Každá distribuce má svůj balíčkovací systém, těžko to někdo sjednotí. Tohle byl jen návrh udělat to trochu jinak. Ale co se týká rozdílnosti, od čeho máme LSB ?

[lefti]

Vlastni balickovaci system je ten nejmensi problem, radove vetsi problem by byl s tim co nastinil muj skoro jmenovec . A toto nikdo jiny nez spravci hlavnich distribuci neporesi. Proto me prijdou vsechny tyhle system jako autopackage (ten zvlast) jako hnus^2

[happy barney]

imho rozumným systémom je zavedenie dedičnosti. Príklad: binárny balíček dedí od zdrojového s nadefinovanými parametrami pre build skripty. (ten istý zdrojový používajú rôzne distribúcie). Môj binárny balíček (napr apache) by bol napr definovaný ako potomok distribučného, s nastavením konfigurácie (napr. DocumentRoot pre apache). Plus drobnosti ako bundle-balíčky (samotná distribúcia len ako bundle-balíček , s možnosťou dedenia a dodania/odstránenia balíčkov/konfiguračných hodnôt), atď.

[regnarg]

Výborný nápad, možná to zařadím do svého návrhu (který se nejspíš nikdy realizace nedočká, ale stejně...)

[vogo]

Ty příklady mi tak nějak nutkavě připomínají křížence ebuildu (gentoo) a PKGBUILDu (archlinux), ze začátku je v tom trochu zmatek, ale nakonec jste došel k modernímu návrhu balíčkovacího systému ;).

Ono jmenovaný Dependency Hell – jeho výskyt ze zvyšuje geometricky s nižší kvalitou balíčků ;D, a obvzláště při nevhodné dekompozici software – oddělení knihoven, různě zvolené a hlavně nevhodně zvolené parametry při kompilaci knihoven a binárek, či podobné záležitosti, kdy balič nemyslí na to, že nechybějící podpora toho, či onoho, může vést k tomu, že někdo jiný udělá balíček toho stejného software s jinými parametry zvolenými při kompilaci – a hlavně s jinou dekompozicí. Je celkem profláklé které distribuce tím kdysi trpěly, trpí…

Myslím že jsem po delší době našel námět na blog ze série rýpavých do vlastních řad… díky ;)

[regnarg]

Z gentoo jsem se samozřejmě inspiroval, ale arch jsem nikdy neviděl a nevím o něm zhola nic...

[Václav "Darm" Novák]

Pak doporučují pročíst si články o jeho balíčkovacím systému právě od Voga

Také mi ten příklad připoměl PGFBUILD. Navíc spoustu zmíněných nevýhod balíčkovací systém Archu nemá.

[Václav "Darm" Novák]

Huh.. PKGBUILD, samozřejmě :)

[rADOn]

tohle je ale docela presny popis jak funguje portage. s tim ze archivy jsou obvykle v "kesovany" v distfiles na portage serverech.
je to zajimava myslenka ale nerealizovatelna. kdyby to byla jen otazka balickovaciho systemu pak by prece melo jit pouzit balicky ze suzle a mindraku v redhotu nebo z kubuntu v debianu - pouzivaji prece stejny balickovaci system.
realita je samozrejme jina, distribuce se lisi v mnohem zakladnejsich vecech a tezko vymyslet abstrakci ktera by pokryla vsechny varianty.
sysv init skripty (redhoti), bsd styl (slack) nebo gentoosacka vymyslenost ? co kdyz nekdo ani nepouziva sysvinit ? patri KDE do /opt (suzle), /usr (fedora ?) nebo /usr/kde (gentoo) ? je libc zkompilovana s linuxthreads nebo ntpl ? selinux kernel, grsec patch nebo stack-protection v gcc ? jsou binarky knihoven protazene prelinkem ? jsou KDE rozdelene na hodne baliku, ale cele (gentoo), prorezane na par dulezitych baliku (kubuntu), nebo balene cele tak jak to buh a KDE-tym zamysleli (slackware) ? pro jakou architekturu jsou baliky kompilovane [hlasity smich z rad gentooistu, zdrojovych magu & spol.] ? existuje vubec zpusob jak donutit vyvojare distribuci aby prestali vymyslet debilni polofunkcni draky, yasty a <dopln-jmeno-distribuce>-controlcentra a radeji pracovali na aplikacich v upstreamu ? kolik milionu podobnych problemu muze existovat ?

[regnarg]

To máte docela pravdu. Část nekompatibility (init skripty a podobné věci) by měl řešit LSB, ale všechno taky ne. Tento návrh si snad ani tak nekladl za cíl vytvoření nějakého "crossdistribution" balíčkovacího systému, protože každá distribuce má svůj, více či méně kvalitní. Vznik nového balíčkovacího systému je jen krůček od vzniku nové distribuce. Tvořit balíčkovací systémy nebo distribuce není zas takový problém, ale kdo "zabalí" desetitisíce programů, když to neudělají autoři ?

[Jardík]

Největší nevýhoda balíčkovácích systému oproti instalátorům z Windows je ta, že si nemůžete vybrat, kam daný program nainstalovat. Spousta cest je zakompilována již v programu, takže i když pak soubory překopírujete jinam, program nefunguje, protože nemůže najít své soubory. A to, že bych měl pak PATH velkou jakkráva není pravda. Přece nepotřebuji mít každý program v PATH. Možná tak ty CLI, ale na co mít třeba Firefox, Kate či ProgramXXX v PATH? Na spuštění programu mi stačí třeba nějaký ten "*.desktop" soubor. Další problém je v knihovnách. Jsou-li v linuxu knihovny u binárky s programem, je to problém. Knihovny se totiž hledají v pár pevně nastavených adresářích a nikoliv v adresáři s binárkou. Aby pak každý program měl vlastní spouštěcí program, který nastaví LD_LIBRARY_PATH. Pro mě je prostě adresářová struktura linuxu (a dalších unixů) fůj.

[happy barney]

to nie je o adresárovej štruktúre, to je o filozofii. Sú veci bezpečné a veci nebezpečné.

[Václav "Darm" Novák]

a k čemu mi bude ten skvělý .desktop soubor když nepoužívám žádné ikonky a programy spouštím přes run dialog? A jaký mám důvod instalovat firefox jinam než kam mi ho dá distro?

[Jardík]

Každý nepoužívá run dialog. Někomu přijde rychlejší poklepat na ikonu na ploše. A proč FF instalovat jinam? Protože ho prostě chci mít jinde. Třeba mi dochází místo na disku a balíčkovací systém si s tím neporadí, tak ho chci mít třeba v /Mount/Data a tam prostě nefunguje, protože svoje soubory hledá v /opt/firefox.

[Smajchl]

Zrovna FF ma na svych strankach archiv se vsema knihovnama, kde staci akorat spustit jeden soubor a je jedno, kde to je. Mel jsem to takhle kdysi v /home, hodi se to kdyz nemas root heslo.

[Jardík]

Přiznávám, že FF je blbý příklad, že zrovna tam to funguje. Ale vemte si nějaký program zkompilovaný s prefixem /usr, který poté hledá svá data (např. *.glade soubory, obrázky) v /usr/share/program. Vezmete binárku z /usr/bin, pár knihoven z /usr/lib patřící onomu programu a přesunete do /opt/program/{bin,lib}. Adresář /usr/share/program dáte do /opt/program/share/program. Jak ale změním (bez kompilace) tu cestu zakompilovanou přímo do programu? Nijak. A ten program bude vesele hledat svá data v /usr/share/program. Ve Windows existuje alespoň funkce, která vám přímo řekne, v jakém adresáři je právě spuštěná binárka. Pak si program v klidu načte svá data z daného podadresáře. V Linuxu to nezjistíte, dokud nenajdete cíl symlinku /proc/PID/exe. A opět jste závislý na tom, že proc fs je připojen do /proc.

[regnarg]

ln -s /opt/program/share/program /usr/share/program. Kouzlo jednoduchosti...

[Smajchl]

Ja osobne jsem nikdy nepotreboval nic davat nekam jinam (jedine jak jsem napsal s tim ff v home, ale to je spis vochcavka spravce), na windows uz vubec ne, tam ma uzivatel prava zapisovat kamkoli, spis jsem to umisteni resil za instalator (matne tusim ze u totalcommanderu), kterej to nechtel instalovat do Program Files, tak sem mu musel rict ze to chci mit pohromade, prave tam

Naopak musim rict ze je lepsi mit konfiguraky v /etc a nebo treba ikonky jsou docela pohromade, kdyz clovek neco hleda, libi se mi to tak jak to je

[Petr "Glubo" Sýkora]

./configure --prefix=/home/jarda/opt/ &&make && make install

[Václav "Darm" Novák]

Ale někdo ano. A tím se dostáváme do problému. Existuje .desktop soubor, ale také je X jiných možností jak ten program spustit. A za mnohých okolností je i ve WM který ikonky podporuje rychlejší spouštět program přes run dialog, cronem, ikonkou na panelu, výběrem z menu, prostřednictvím jiného programu. (Jak mě jenom štvala nutnost zadávat plnou cestu k programu ve firefoxu)

Nemít binárky v PATH je imho cesta do pekel, za menší problém (alespoň problém pro vás, instalace pouze do vybraných adresářů) tu máme podstatně větší problém a spoustu naštvaných uživatelů nadávajících na nutnost neustále hledat cestu k programu. Hurá.

[Smajchl]

s tim firefoxem to je presny

Navic mas vsechny binarky pohromade a muzes se podivat co vsechno v systemu mas.

[regnarg]

Pokud je třeba kvůli nedostatku místa přesouvat software na jiné oddíly, je to patrně způsobeno špatnou úvahou při rozdělování oddílů...

[Jardík]

To těžko, když dáte všechno na /, tak to asi špatně rozdělené nebude

[regnarg]

No, ideální to není, ale potom by přece neměl vznikat problém s nedostatkem místa který by šlo vyřešit přesunutím jinam...

[Smajchl]

asi je to jinej fyzickej disk, ale i to se da vyresit

[Käyttäjä 11133]

pak je odpovědí LVM :)

[lefti]

Rekneme, ze pres balickovaci system nainstalujes nejaky program s web rozhranim - prece nebude delat takove prasarny, aby si poustel vlastni webovy server - tudiz by si ho rad nainstalovat tam kde mas nastaveny "documentroot" .... a kdyby si to mohl udelat ve spolupraci s balickovacim system - no nebylo by to idealni ?

[regnarg]

To by bylo. Jenže by také bylo třeba počítat s tím, že uživatel může používat různé webservery s různou konfigurací a ne všechny mohou být pro daný program dostačující. Navíc ne vždy by bylo ideální cpát něco do document root.

[regnarg]

S tímhle bych si dovolil zcela nesouhlasit, protože právě přístup používaný v GNU/Linuxu považuji za velkou přednost. Mít programy v $PATH je velmi důležité, možná důležitější, než si kdo může uvědomit. A navíc je to tak pohodlné, když je program identifikován svým názvem a nepotřebuji žádnou cestu, žádné procházecí dialogy, nic. Jen název. To je přeci kouzlo unixových systémů. GNU/Linux není w*****s.

[Jardík]

A co když se 2 programy jmenují stejně? To si jako navzájem budou přepisovat binárky? A neříkejte, že se to nestává. Už jsem vyděl program na převod CD obrazu Clone-CD na ISO a v recenzi radši napsali hodně velkým písmem, ať to nikdo nezkouší instalovat příkazem make install, protože to přepisuje pár systémových binárek.

[regnarg]

Tak je třeba jeden z nich přejmenovat. Nebo se domluvit s autory a zjednat nápravu. Nelze řešit chybu autorů několika málo programů způsobem, který absolutně zlikviduje pohodlí unixového systému. Možná tomu nebudete věřit, ale existují i uživatelé, kteří nemají jen ikonky na ploše (já tam třeba mám terminál a spouštět něco s plnou cestou by mě zabilo)...

[Bluebear]

Balíčkovací systém by neměl dopustit, aby si dva balíčky přepsaly binárky nebo jakýkoli jiný soubor - v takovém případě nesmí dovolit nainstalovat ten druhý. Uživatel sice nemůže používat oba, ale aspoň nepoškodí ani systém, ani to, co už má nainstalované.

Jinak, myslím, že vytvoření unikátního názvu není zase takový problém; už jsem párkrát viděl, jak se to stalo a autoři projektů se rozumně dohodli, že někdo z nich svůj projekt přejmenuje. Dva stejně se jmenující projekty způsobují zmatky nejenom v systému, ale i všude jinde, takže je v zájmu obou stran se domluvit.

Pokud nějaký program při make install přepíše systémové binárky, tak je jeho autor nebetyčné čuně.

[Käyttäjä 11133]

hodně velkým písmem, ať to nikdo nezkouší instalovat příkazem make install

AND

Balíčkovací systém by neměl dopustit, aby si dva balíčky přepsaly binárky nebo jakýkoli jiný soubor

=> make install asi nebude součáští nějakého balíčkovacího systému. :)

A myslím si, že by nebylo od věci mít možnost takový přepis povolit, pokud to explicitně balíkář povolí, zajisté po zralé úvaze. A myslím si, že se tak děje běžně, ale jen za předpokladu, že soubor nebyl změněn. Tedy pokud nainstaluješ apache z balíku a hned poté (ještě než upravíš konfiguráky) nainstaluješ php, tak si ten balík php upraví konfigurák apache, pokud dále nainstaluješ mysql a ještě si neupravil php.ini tak si to IMHO opět povolí dynamický modul pro spolupráci mysql a php.

[Petr "Glubo" Sýkora]

V tomto případě fungují v současné době v zásadě dvě relativně funkční řešení -- buďto modulární konfigurační soubory, tedy jakýsi adresář konfigurace.d, do kterého si dané balíčky přidávají jednotlivé úseky konfiguračních souborů, které popisují změny v konfiguraci k nastavení nějakého balíku aby používal jiné balíky a ten "nadřazený balík" buďto pak jednoduše podle nějakých pravidel zahrne soubory z tohoto adresáře, nebo mu balíčkovací systém z těchto fragmentů sestaví jeho konfigurační soubor, což je ale poněkud drahé řešení pro použití pro každý balík.

Proto existují ještě další přístupy, například ala etc-update z gentoo, kdy pokud dojde k situaci, kdy je při instalaci balíku třeba upravit stávající konfigurační soubor, pouze se chtěné změny přidají do jakésy fronty, načež při zavolání etc-update se podívá do této fronty a vypíše se seznam dotknutých konfiguráků, člověk se pak může podívat, jaké změny to jsou, přijmout je, či zahodit, nebo jakousy interaktivní formou přijmout část z nich.

Co mi přijde trochu líto je, že zatím žádná mně známá distribuce nepoužívá na /etc nějak relativně transparentně správu verzí. Já sám si používám git a když člověk najednou zjistí, že něco, co mu před rokem fungovalo a najednou nefunguje, nebo že omylem si nechal přepsat konfigurák, ve tkerém narobil spousty vlastních změn, není pak problém se vrátit ke starší konfiguraci. Jenom to vyžaduje ručně se o tento git repozitář starat, což sice není nic těžkého, ale je to přeci jenom práce navíc, která by podle mně měla spíše být zahrnutá do balíčkovacího systému alespoň stylem -- potřebuji něco změnit, commitnu případné změny doteď, provedu chtěné změny a commitnu znovu.

[regnarg]

Mimochodem, někde jsem četl o distribuci která používá adresářovou strukturu ala nejmenovaný OS. Ale to je pro většinu uživatelů GNU/Linuxu, kteří opravdu chtějí používat linuxový systém a ne "free w*****s", něco nemyslitelného. My máme náš adresářový systém rádi. Tečka.

[Jardík]

Ano, mějte ho rádi, jak je. Já jen říkám, že se to nelíbí mně a pár jiným. Například jeden kamarád ze školy zkoušel Linux a nadával právě na tu strukturu, že je to strašně nepřehledné. Pak se ptá, jak nainstalovat program tenaten do adresáře tohoatoho. Řekne te mu, že to nejde a on si akorát řekne "Ten Linux stojí ale za ho*no".

[Kyosuke]

jak nainstalovat program tenaten do adresáře tohoatoho

To je jednoduché: ./configure --prefix=/home/ja/mujvlastniadresar - a nic mimo nepocuchám. A žádné řeči o kompilaci, pokud vymýšlím kraviny, dostanu zákonitě kravskou odpověď.

[regnarg]

To je samozřejmě možné, ale k čemu běžnému uživateli bude, že nainstaluje program A do adresáře B ?

[Lu-Tze]

No spíš bych se ptal: "Na co bude běžnému uživateli, když si bude moci sám nainstalovat program?" Bez kompilování.

[Jardík]

Proč by si běžný uživatel nemohl nainstalovat program? Běžný uživatel domácího desktopového PC si sám běžně instaluje operační systém a programy. Na tom není nic nenormálního. Každý nepotřebuje mít doma administrátora, aby mu to udělal.

[xkesh]

Proč by si běžný uživatel nemohl nainstalovat program? Běžný uživatel domácího desktopového PC si sám běžně instaluje operační systém a programy. Na tom není nic nenormálního. Každý nepotřebuje mít doma administrátora, aby mu to udělal.

Odpověď se netýkala instalace samotné, ale umístění instalovaných souborů. Ale poslední větou jste si odpověděl sám: Právě že každý nemusí mít doma administrátora, aby mu určoval, kam který soubor má přijít, že... Takže to prostě nechám na balíčkovacím systému, a když chci vyvádět psí kusy, tak si je vyvádím pomocí prefixu při kompilaci

[Bluebear]

Největší nevýhoda balíčkovácích systému oproti instalátorům z Windows je ta, že si nemůžete vybrat, kam daný program nainstalovat. Spousta cest je zakompilována již v programu, takže i když pak soubory překopírujete jinam, program nefunguje, protože nemůže najít své soubory.

Myslím, že tahle vlastnost se naopak vyčítala programům pod Windows - instalátor, někdy i program samotný, měl natvrdo nastaveno, že se spouští z podadresáře C:\Program Files, v horším případě C:\PROGRA~1, a basta fidli.

[Jardík]

Bývávalo kdysi dávno v érách Win95 a bylo to způsobeno neznalostí (či leností) programátorů jakou API fci zavolat pro zjištění adresářů, kde je systémový disk, kde je binárka, kde je dočasný adresář, ...

[vogo]

zajímavé tvrzení, tak namátkou třeba v Archu si můžu změnit cestu kam instalovat dle libosti, a pak si taky dle libosti můžu nastavit systém tak, aby spouštěl tu či onu verzi, kterou mám tam či onde... stačí umět ovládat balíčkovací systém

[Jardík]

Hrát si se symlinky umí každé malé děcko, ale to není řešení mít všude samé linky. Když přes pacmana instaluješ něco jinam, musí se mu předat parametr pro změnu kořenového adresáře, ale program pak nenajde svoje soubory. Úpravou PKGBUILDu nezmizí problém, že je cesta opět zakompilovaná v programu.

[vogo]

obvykle stačí mít správně nastavené proměnné systému :)), asi jsem naprosto neschopný ;) ale nechápu, to s těmi „zakompilovanými“ cestami :), to že je binárka jinde mi zatím problém nedělalo, jen stačilo přidat adresář s knihovnami do cest, stejně jako binárky se přidají do cest, prostě to funguje…

[Petr "Glubo" Sýkora]

Jenže ne každý balík se sestává puze z binárky, ale třeba také konfiguračních souborů, nějakých dat, nějakých logů... A pokud by člověk hypeteticky chtěl mít vše na jednom místě, jiná cesta než přes --prefix bohužel většinou nebývá, u některých projektů bohužel ani s použitím --prefix nepočítají.

[Käyttäjä 11133]

Jo to pak musí opravovat balíkáři :) takže se stačí podívat do .src.rpm, nebo ebuildu,.. a vytáhnout si ty správné patche na Makefile :)