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

4.7.2007 15:44 | Přečteno: 1133× | GNU/Linux

Balíčkovací systémy jsou jistě tématem, které hodně hýbe světem GNU/Linuxu. Jedni je vynášejí, jiní zatracují. Co vlastně balíčkovací systémy přináší ?

První bod je jasný. Snadná instalace programů. I když pojem "snadná" je velmi relativní, sám dobře vzpomínám na hodiny strávené na rpmfindu hledáním závislostí. Závislosti jsou vůbec jednou z nejvíce kritizovaních vlastností balíčkovacích systémů. Jenže narozdíl od skutečného světa mohou být tyto závislosti velmi užitečné. Protože kdyby balíčkovací systém neřešil závislosti, nainstalovali byste program a zjistili, že nejde. Chybí libxyzblbost.so.4. Ale kde sehnat libxyzblbost ve správné verzi ? Bez balíčkovacích systémů vám zbývá google, najít správnou verzi projektu, zkompilovat, případně nainstalovat a zjistit, že nefunguje, protože se nesnese libnesmysl.so.5 verze 1.14.3. Balíčkovací systém alespoň ví, co přesně potřebujete — který balíček. Ale ani tohle řešení není zcela ideální. Když najdete a stáhnete potřebné balíčky (což je o něco jednodušší díky službám typu rpmfind), zjistíte, že vyžadují další balíčky, a ty mají další závislosti. Tomuto jevu se říká dependency hell a je často kritizován uživateli OS, který se nejmenuje. Jenže zapomínají na obrovské výhody tohoto systému. Nemusíme nic psát dvakrát. V nejmenovaném OS si každý program řeší všechno sám za sebe, vznikají složité nesourodé balasty bez návaznosti na okolní prostředí. Ve světě GNU/Linuxu je to jinak. Vývojáři se snaží o maximální využití existujícího kódu a doboru spolupráci programů. A od tohu zde máme systém závislostí. Pravda, instalece programů tímto způsobem nebyla nejjednodušší a dalo se tím strávit nějakých pár hodin.

Ale samozřejmě vývoj jde kupředu a objevuje se nový trend — repozitáře. Ty zdánlivě řeší mnoho nevýhod stávajícího systému. Nemusíte hledat balíčky — chcete firefox ? Napište impkg install firefox a máte. Nemusíte řešit závislosti, balíčkovací systém je natolik inteligentní, že je všechny v repozitářích vyhledá a automaticky stáhne a nainstaluje (s vaším souhlasem). Je to výrazný pokrok oproti předchozí variantě, ale má jeden velký nedostatek. Co když se daný balíček nenachází v repozitářích vaší distribuce ani jiných kompatibilních repozitářích ? Většina balíčkovacích systémů založených na repozitářích nabízí i klasickou variantu — instalaci balíčků běžným způsobem ze souboru. Jenže na takovouto instalaci se zase většinou nevztahují výhody repozitářů a automatické řešení závislostí. Závislosti si proto musíte nainstalovat sami — většinou z repozitářů, což je celkem jednoduché, ale přesto je nepochopitelné, proč tato činnost často není balíčkovacím systémem vykonána automaticky. Ale závislosti, které nenajdeme v repozitářích, musíme sehnat a nainstalovat klasickým způsobem a opět se vracíme do raných dob rpm.

Jako taková menší odbočka se v této době začaly objevovat různé "nebalíčkové" systémy instalace, spíše podobné instalátorům v OS, který nesmíme jmenovat. Tyto nástroje často neřeší závislosti vůbec — spoléhají na určitou základní množinu knihoven, která musí být na cílovém systému přítomna (glibc, gtk+, ...) a zbytek je přibalen. Zde je zcela evidentní, že se nejedná o moc inteligentní řešení, o čemž svědčí i jeho původ.

Další změnou na poli balíčkových systémů byly systémy využívající balíčky ze zdrojového kódu. Tyto systémy kombinují většinu (ne)výhod balíčkovacích systémů s většinou (ne)výhod kompilace programů. Výrazně se zvyšuje čas potřebný k instalaci balíčků, zároveň se ale zvyšuje rychlost a přizpůsobitelnost programů, což ocení převážně pokročilí uživatelé. Ovšem i tyto nástroje kopírují klasické rysy balíčkovacích systémů, ať už jde o závislosti nebo repozitáře, a objevují se stejné problémy.

Proto rozumným krokem ve vývoji balíčkovacích systémů je sjednocení repository a non-repository balíčků. Jednou z mnoha myšlenek je identifikace balíčků pomocí URL, která tak vlastně vytváří z celého internetu jeden velký repozitář. Instalace je poté pohodlná i u programů, které nejsou součástí distribuce, prostě napíšete impkg install http://program.example.org/program-1.0. Ovšem zde je problém nejednoznačnosti. Jak mám balíčkovací systém poznat, že http://nesmysl.com/libgtk-2.6 a http://packages.imdistro.org/pkg/gtk2-2.6 jsou balíčky stejné knihovny ? Některé programy si jako závislost mohou vybrat první URL, jiné druhou. Systém potom nainstaluje oba (zdánlivě rozdílné) balíčky a vzniknou konflikty. V podstatě ať přemýšlíte nad otázkou správného řešení balíčků jakkoliv, ideální řešení neexistuje. Ale můžeme se mu libovolně přibližovat. Proto další rozšíření předchozího nápadu zahrnuje jednoznačné názvy balíčků. Tyto názvy by se měly vytvářet podle jednotných pravidel, ideálně po dohodě s autorem programu, aby byly skutečně jednotné. Potom je jedno, jestli instalujete http://gtk.org/gtk2/2.6 nebo http://impkg.nesmysly.com/gkt2-ultimate/gtk2/2.6-u. Systém rozliší stejný název a vybere nejvíc vyhovující verzi. Zároveň si sebou distribuce může nést připravený seznam vzorů URL, kde se dají hledat balíčky přímo podle názvu. Takže v /etc/impkg.conf bude např. http://packages.imaginarninesmysl.net/ a při požadavku impkg install program se vybere http://packages.imaginarninesmysl.net/program, pokud existuje. Pokud ne, zkusí další položku v seznamu atd.

I toto řešení má značnou nevýhodu v neexistenci seznamu balíčků, kde by si uživatel neznalý konkrétního názvu mohl vybrat, co hledá. To ale není příliš velký problém, stačí přidat katalog balíčků, který si nese popisy balíčků spolu s jejich URL. Ten by bylo možné vytvářet automaticky se zadáním URL zdrojů, které by obsahovaly potřebné metainformace.

Takže finální podoba tohoto návrhu je (nemám tušení, zda něco podobného někde existuje, či nikoliv; veškerá podobnost se skutečnými implementacemi je čistě náhodná): balíčky identifikujete podle jednoznačného názvu a podle URL, která také odpovídá fyzickému umístění balíčku. URL může vypadat jako http://server/cesta/název nebo http://server/cesta/název/verze pro instalaci kontkrétní verze. V adresáři /cesta/název/verze na serveru pak leží balíček verinfo s informacemi o balíčku, popisem, definicí závislostí, atd. Např:

#IS:text.config.impkg-verinfo
#impkg package file for package gtkBlbost
[Package]
pkgname=blbost
version=0.1

[Files]
data=http://server/data/blbost-0.1.tar.bz2 
configfiles=/etc/blbost.conf /etc/.blbostrc #nebodou mazány ani přepisovány
scripts=preinstall postremove #seznam skriptů z dataarchivu (z adresáře např. .scripts),
                              #které jsou spouštěny při daných operacích (instalace, odstranění, update, ...)

[Locations] 
#nutno uvést lokace všech vyžadovaných balíčků pro případ, že systém žádné implicitní nemá
#ale správce balíčků ma plné právo použít jiné lokace dle vlastního či uživatelova uvážení
gtk2=http://packages.impkg.org/gtk2
blbost-extras=http://server/cesta/blbost-extras
#nesmysl není definován, protože je vyžadována pouze jeho nepřítomnost

[Dependencies]
require gtk2 >=2.4
recommend gtk2 >=2.6
suggest blbost-extras =0.1
require !nesmysl #nesnese se s konkurenčním programem

[Changelog]
...

a v nadřazeném adresáři soubor pkginfo se souhrným obsahem, např.

#IS:text.conf.impkg-info
[Package]
pkgname=blbost
url=http://server/cesta/blbost
[About]
#informace pro katalog
category=misc #nezařaditelné
name=gtkBlbost
desc=Absolutní blbost
[Versions]
all=0.1 0.2 0.3b
latest=0.3b
stable=0.1
testing=0.2
devel=0.3b

Takovýto systém by mohl fungovat jak pro kompilované balíčky ala Gentoo, tak pro binární. To ale pro tuto chvíli není podstatné. Takže každý balíček by měl podobné definice a soubory ke stažení. Vlastní balíčkovací systém také musí mít jednoduchou konfiguraci, např. /etc/impkg.conf:

#impkg configuration file
[Prefs]
preferred=devel #stable, testing, devel, cvs, ...

[Locations]
gtk2=http://gtk.impkg.org/gtk2

[Repositories] #url "repozitářů" ve kterých zkouší hledat balíčky
http://packages.impkg.org
http://packages.imdistro.org
sftp://customer1453:heslo@store.impkg.com

Potom by bylo možné instalovat klasickým způsobem:

impkg install http://server/cesta/blbost
impkg install http://server/cesta/blbost/1.0
impkg install http://server/cesta/blbost 1.0
impkg install http://server/cesta/blbost testing
impkg install blbost     #za předpokladu, že je
impkg install blbost 1.0 #v některém z "repozitářů",
                         #tedy implicitních vzorů URL

Odstraňování by bylo ještě jednodušší prostě impkg remove blbost, potom samozřejmě aktualizace typu impkg update blbost nebo rovnou impkg system-update. Ovšem dalším faktem je, že spousta současných repository-based správců balíčku opomíjí uživatele nedisponující připojením k internetu, přesněji disponující, ale na jiném počítači. Ti se musí spokojit s klasickou zdlouhavou metodou. Přitom řešení je tak jednoduché. Vyexportovat informace o nastavení balíčkovacího systému a nasinstalovaných balíčcích do jednoho souboru, ten přenést na libovolném médiu na počítač s internetem, stáhnout vše potřebné do speciálního archivu, který se opět importuje na cílovém počítači. Např. impkg export >/media/usbdisk/my.ipe, a na druhém počítači se použije jednoduchá utilitka imdl, která nevyžaduje ani instalaci (pokud v systému není přítomen impkg). Nejdříve se připraví a otevře cílový archiv, např. imdl open /media/sdb1/my.ipe /media/sdb1/programy.ipi (první soubor jsou vyexportované informace o balíčcích a druhý je název archivu, do kterého se budou ukládat stažené programy). Poté je možno používat imdl stejným způsobem jako impkg, např imdl install blbost. Nakonec je třeba ukončit práci s archivem, např imdl close. Archiv lze potom naimportovat na původním počítači, např. impkg import /media/usbdisk/programy.ipi. Je to rozhodně o něco jednodušší než ruční stahování balíčků...

V předchozím odstavci jsem jen tak zhruba nastínil, jak bych si představoval implementaci dobrého balíčkovacího systému. Přemýšlel jsem o tom docela dlouho, a žádné lepší řešení mě nenapadlo. Pokud máte nějaké rozumné nápady, můžete se o ně podělit s ostatními v komentářích. Popsané kategorie balíčkovacích systémů byly brány zcela obecně, avšak většina z nich doopravdy existuje minimálně v jednom exempláři. Já jsem zatím víceméně spokojeným uživatelem gentoo, ale instalace čehokoliv mimo repozitáře je hrozná. PORTDIR_OVERLAY už mi leze krkem a zdá se mi, že k nainstalování takovéhoto balíčku je třeba až příliš mnoho úkonů, nemluvě o udržování programu aktuálního. Jisté řešení se pokouší nabídnout layman, ale stále jsou nejčastěji šířeny samotné ebuildy. impkg v tomto textu označuje imaginární balíčkovací systém, pod kterým si můžete představit cokoliv. Nemám čas ani chuť nastíněné myšlenky implementovat a nechat vzniknout tisícprvní balíčkovací systém, už takhle je jich dost. Berte to jen jako námět k zamyšlení nad stávající implementací, třeba to někoho inspiruje...

       

Komentáře

[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 :)