Nový způsob instalace software v Linuxu

20.11.2006 23:19 | Přečteno: 5361× | Linux

Už poměrně dlouho nosím v hlavě myšlenku, jakým způsobem by se (nejen) pro BFU dala zjednodušit instalace software v Linuxu. Možná si řeknete ... moment moment, vždyť stačí napsat aptitude/yum/urpmi/pacman/emerge/... název_balíku a máme vše z krku. A pokud se bojí konzole, máme tu ženiální grafické nadstavby, jako kpackage, yast, nebo synaptic.

Jenže BFU přemýšlí jinak. Někde na síti si najde článek o nějakém super programu. Ihned se ho rozhodne vyzkoušet a první co uvidí je adresa ke stažení. Jenže ta stáhne nějaké divné tar.gz, nebo tar.bz2 soubory a už to nejde nainstalovat klikem z grafického správce, jako ty předtím. V horším případě od Linuxu úplně uteče, v lepším ten zdroják zahodí a v tom úplně nejhorším případě se náš BFU zeptá Jak nainstaluji balíček s příponou tar.gz. Čeká ho zatracená svatá trojice a dost možná se mu ten balíček do systému povede nacpat ...

Jak je vidět v předchozím zápisku na toto téma, řešení není jednoduché. Můj nápad s vypsáním instalačních příkazů pro všechny distribuce byl naštěstí tak šílený, že si ho prakticky nikdo nevšiml

Rozhodný požadavek

Co tedy potřebujeme? Potřebujeme jeden, distribučně (možná i platformně) nezávislý odkaz, který bude mít po své aktivaci za následek instalaci daného balíku té dané distribuce. Lidsky řečeno, na stránkách amaroku klikneme na odkaz instalace, spustí se nám nějaké udělátko, které nám v Debianu/Ubuntu provede aptitude install amarok, v Gentoo emerge amarok, ve Fedoře yum install amarok ... no a až se prosadí smart, tak pouze smart install amarok. To, co je podstatné je, že v žádném případě nechceme obcházet balíčkovací systém! Ne, pouze chceme zjednodušit počáteční fázi instalace. Je samozřejmě jasné, že v distribucích typu Slackware, nebo LFS nic podobného fungovat nebude. Ale to je daň za nepoužívání řešení závislostí.

Featurky

Protože už ten nápad nosím v hlavě nějakou dobu, prošel různými stádii. Od prvních nejasných počátků, po velké nadšení a přidávání ultra super vlastností, až po pokusné implementace a odebírání vlastností až na samotný základ.

• Jedná se o nástroj pro BFU. To, že tím nepůjde instalovat třeba glibc nemusí vůbec vadit. Primárním cílem je software typu amarok, nebo xara extreme.
• Není to nový speciální balíčkovací systém, pouze pokud o automatické zavolání stávajícího instalátoru.
• Rovněž to není pokus o jeho obcházení, naopak, primárním cílem je jeho co největší používání.
• Dokonce v první fázi neplánuji ani podporu pro update, nebo smazání balíčku (možná hloupost)
• Ovšem systém by měl mít i informace o balíčcích, které nejsou ve standardních repository a ty umět automaticky zavést ...
• Cílem je vytvořit systém pro instalaci software z webu na jedno (několik) kliknutí - geeky raději upozorňuji, že konzoli jim to skutečně nesmaže

Proof of concept*

Celé jsem to pojmenoval webbin (web based installer) a prvotní nástřel webbin-concept.tar.gz se sestává ze 4 souborů:

1. amarok.wbn - XML popisný soubor. Obsahuje nějaké informace, ale především package_name, což je jednoznačný a unikátní identifikátor balíčku.
2. config.py - distribučně závislá část (původně jsem měl vymyšlené složité heuristiky ), která obsahuje konfigurační data.
3. ubuntu_6.10.xml - další distribučně závislá část. V podstatě je to databáze, kde klíči jednotlivých záznamů jsou ony unikátní identifikátory balíčků. Tento soubor by si měl tvořit distributor sám. Je možné použít i stávající soubor Packages (nebo ekvivalentní).
4. webbin.py - je vlastní kód. Je to jen koncept, takže se tolik nedivte (v kódu uvidíte reimplementaci Xpath pomocí stručných generátorů ).

*proof of concept pochopitelně znamená, že když někde použiji xml soubor místo databáze, není to špatně a pro demonstraci to stačí . Rovněž fakt, že je to textové není problém, protože dokud nebudu mít představu o vnitřnostech, není kam spěchat. Pochopitelně se počítá s vytvořením Qt/Gtk verze. Navíc se nemusíte bát o systém, protože aplikace mimo výpisu textu nic nedělá.

Jak to pracuje. Příkaz python webbin.py amarok.wbn si ze souboru amarok.wbn vyčte potřebné informace, ale především unikátní název balíku. Ten dá potom vyhledat v databázi. Dlouho jsem si lámal hlavu, jak vyřešit verze, ale nakonec jsem přišel na to, že to není možné. TO, co vidíte v xml souboru je odlišný způsob ... verze se rozdělí do několika tříd (např) na stable, latest a třeba development. Uživatel si zvolí prioritní způsob instalace (anebo jej pro konkrétní případ překryje). Tím se obejde rozdílné verze v rozdílných distribucích. Také je možné, aby si každá distribuce zvolila systém pojmenování vlastní. Dovedu si představit Debianí třídy stable, testing, unstable, od Mandrivy třeba stable a cooker, Gentoo stable, masked, hard-masked a cvs/svn/git-overlay a v Archu tohle vůbec neřeší

Díky tomu, že víme, ze které repository daný balík pochází, můžeme ji nechat přidat do seznamu standardních zdrojů, provést update a instalaci.

Kde zatím tápu ... software mimo repository (a navíc dostupný jenom jako rpm v deb systému). Udělat (nebo alespoň přemýšlet o integraci) s autopackage, nebo s loki instalátorem? Tak, aby Sun mohl napsat takový netbeans.wbn. Další věcí by byla podpora src balíčků.

Takže co na to říkáte?

       

Komentáře

[xkesh]

No, snahy přece jsou, existují projekty jako Klick anebo řešení z PC-BSD. Tam se dá instalovat klikáním na balíček... Sice se tím obchází package manager, ale protože si každý program tahá knihovny s sebou, tak k čemu pak package manager? Co by ten měl spravovat?

Osobně považuji zavedený systém pomocí package manageru za daleko lepší řešení než hledat, stahovat a instalovat bezhlavě kdejaký bordel. Proto bych právě takový styl instalace od package manageru striktně oddělil, podobně jako je to např. u PC-BSD. Ručně si pak můžete instalovat zkušební blbinky anebo nouzová řešení. Klíčové programy, pro něž jsou třeba speciální nastavení nebo extra závislosti, jakož i aktualizace a upgrady, pak pomocí package manageru.

Jiná věc by byla např. sjednocení např. názvů balíčků, aby se jmenovaly ve všech distribucích stejně...

Dejte si taky pozor, že přemýšlíte příliš komplexně, tj. z pohledu uživatelů "Linuxu", tj. všech distribucí najednou. V reálu to ale přece je tak, že člověk nakonec zakotví jen u jedné distribuce (pokud jich má víc, tak je to experimentátor a těm není třeba něco ulehčovat). Přece jen, každá distribuce je samostatný operační systém.

[Michal Vyskočil]

Primárním cílem není instalace na kliknutí, ale zjednodušení prvního kroku instalace a především důsledné používání stávajícího balíčkovacího systému. Pokud nebude daný balíček k dispozici, mohlo by to umět vyřešit problém jinak, ale způsob zatím nevím ...

[Saljack]

Kdyby balíček nebyl k dispozici mohl by se vytvořit ze zdrojáků to by šlo ne(nemám s tím zkušenosti ale deb balíčky takhle jdou)

[kotyz]

i rpm balicky takhle jdou - kompilace + checkinstall. vyzkousene, funkcni.

[Kníže Ignor]

To si jenom myslíš

[Käyttäjä 11133]

My dva a mít stejný názor?! Co se to stalo?

[Käyttäjä 11133]

checkinstall

někdo neměl dlouho rozbitý systém, že?

[Michal Kubeček]

Nebo už je naopak rozvrtaný tak, že už mu checkinstall nemůže ublížit… :-)

[Käyttäjä 11133]

Taky pravda.

[marbu]

pokus mate Slackware, tak se zas tak nic hroznyho nedeje, ne? :)

[Michal Vyskočil]

Nešlo. Respektive šlo, ale špatně, protože počet možných komplikací, které by se musely řešit je velký. V tomto ohledu bych se držel unixové filozofie KISS. Tedy program by měl dělat jednu věc, ale pořádně. Nechci řešit automatickou kompilaci, která by v 90% jela správně a ve zbylých 10% případů ne, nejsem z Microsoftu

Raději bych přidal nějaké čudlítko na vytvoření requestu pro přidání balíku (návodu pro instalaci, nebo tak).

[xkesh]

Primárním cílem není instalace na kliknutí, ale zjednodušení prvního kroku instalace

Pro ...? Uživatele nebo vývojáře distribuce? Z mého pohledu je nejjednodušší, když si v menu distra např. vyberu program a kliknu na tlačítko: Nainstalovat. Blblblbl... nějaká akce, co mě už vůbec nepotřebuje a hotovo.

Kvalita distra pak bude v tom, jak kvalitní bude programová nabídka tímto způsobem instalovatelná - to by mohlo souviset s tím, že z hlediska vývojáře by bylo lepší nalézt nějaký univerzální způsob prezentace balíčků, aby se nemusely donekonečna nafukovat repozitáře, o které se pak nakonec nemá kdo starat. Často také hodně udělají distribuční patche - tohle by odpadlo?

Courat po netu a stahovat si odsud ručně software, to nepozvažuji jako uživatel za pohodlný způsob existence a jsem velice rád, že to v Linuxu obecně nemusím. Může to být zajímavá kratochvíle nebo hobby, to ano... ale pak to nepotřebuji mít až tak ulehčeno, asi ani ten první krok.

a především důsledné používání stávajícího balíčkovacího systému. Pokud nebude daný balíček k dispozici, mohlo by to umět vyřešit problém jinak, ale způsob zatím nevím ...

Tím spíš to ale vidím spíše jako nástroj pro vývojáře, kteří ho pak zakomponují do vlastního spráce distribuce. BFU by de facto ani neměl na něco takového pomyslet, i když by si mohl umět nainstalovat programy skrze správce balíčků.

[Michal Vyskočil]

Já ale nevymýšlím žádný naprosto nový způsob balíčkování v Linuxu Pouze se snažím zakrýt ten krok navíc, co musí uživatel udělat pro instalaci nějakého programu s použití stávajících prostředků.

Postup na Windows: vidím to, zaujme mě to, kliknu na odkaz a nainstaluju.

Postup na Linuxu: vidím to, zaujme mě to ---> přepnu se do úplně jiného programu, chvíli hledám (ev. hledám repository a přidávám je) ---> nainstaluju.

Moje řešení: vidím to, zaujme mě to, kliknu na odkaz (webbin to přeloží na název balíčku, ev si přidá repo a zavolá stávající systém) a nainstaluju.

Já vím, že pro člověka, který zná balíčkovací systém a konzoli není problém při čtení článku o amaroku napsat aptitude search amarok (vim /etc/apt/sources.list, aptitude update) a aptitude install amarok. Jenže co chudák BFU, pro nějž jsou tohle hieroglify? Navíc, můj nápad vůbec neodstraňuje možnosti instalaci z konzole, takže vyhledávat balíčky na webu není nutné. Nic stávajícího měnit nechci.

Ten tvůj způsob výběru z nějakého menu je běžně v grafických instalátorech - kpackage, yast, synaptic, nebo textové aptitude a naráží na množství balíčků. V takovém Debianu je kolem 20 000 balíčků (Gentoo kdysi uvádělo kolem 15 000) a vyhledávat v tomto množství není jednoduché ani pro zkušené uživatele (aneb kolikrát jste zjistili, že ten super program, o kterém právě čtete už máte dávno v repository)

Co se týká univerzálních balíčků, docela se mi líbí autopackage.org ... možná se ještě zkusím podívat co nabízí on.

[David Watzke]

Postup na Windows: vidím to, zaujme mě to, kliknu na odkaz a nainstaluju.

Postup na Linuxu: vidím to, zaujme mě to ---> přepnu se do úplně jiného programu, chvíli hledám (ev. hledám repository a přidávám je) ---> nainstaluju.

Moje řešení: vidím to, zaujme mě to, kliknu na odkaz (webbin to přeloží na název balíčku, ev si přidá repo a zavolá stávající systém) a nainstaluju.

Moje řešení: vidím to, zaujme mě to, řeknu emerge to. Když se nudím a autoři používají CVS/SVN/GIT, napíšu pro to ebuild a hodím ho do overlaye

[xkesh]

Postup na Windows: vidím to, zaujme mě to, kliknu na odkaz a nainstaluju.

Postup na Linuxu: vidím to, zaujme mě to ---> přepnu se

Hm, u mě to vypadá takto: Něco potřebuju, poptám se, popátrám, jestli něco takového existuje a jak se to jmenuje, prohledám repozitáře své distribuce, nainstaluji, vyzkouším. Hledám-li návod nebo když mám problémy, jdu se podívat do fóra distribuce / přes Google na www / na homepage programu (mám zkušenosti, že relevantní informace najdu v tomto pořadí).

Ale ano, pochopil jsem, že vaše idea by leckomu instalace usnadnila... Jen bych ještě přece jen připodotkl, že obecně jako uživatel Linuxu nemám vůbec potřebu instalovat spoustu malých kravinek, jako to bylo za dávných časů s Windows. Částečně je to tím, že užitečné maličkosti jsou často už defaultně obsaženy, stačí je jen objevit, a taky snad tím, že člověk má zábavy dost se systémem samotným. Tedy bych si dovolil tvrdit, že představa linuxáka bloudícího po netu a hledajícího "nějaké" programy, co by ho mohly zaujmout, je mi dost vzdálená.

Tím nic proti záměru, pouze si jen tak přemýšlím, jestli bych to já využil vzhledem ke svým návykům. Jinak jsem zastánce usnadňování co to jde.

[Michal Vyskočil]

Tedy bych si dovolil tvrdit, že představa linuxáka bloudícího po netu a hledajícího "nějaké" programy, co by ho mohly zaujmout, je mi dost vzdálená.

No linuxáka snad ne (já tohle chápu jako velkou výhodu Linuxu, škoda, že to není marketingově zdůrazňováno), ale co lidé mající Linux (a jsou plní náviků z Windows) chvilku? Škoda, že se tu neozvali.

Tím nic proti záměru, pouze si jen tak přemýšlím, jestli bych to já využil vzhledem ke svým návykům. Jinak jsem zastánce usnadňování co to jde.

Částečně to řeší i ten problém na co linkovat, když ne na zdrojáky, jak jsi psal v blogu. Já osobně umím používat balíčky a chápu jejich princip a výhody. takového.

[David Watzke]

... náviků z Windows ...

No ale Michale... styď se!

[Dalibor Smolík]

Vždyť je to správně! Malej, měkkej

[Michal Kubeček]

No linuxáka snad ne (já tohle chápu jako velkou výhodu Linuxu, škoda, že to není marketingově zdůrazňováno), ale co lidé mající Linux (a jsou plní náviků z Windows) chvilku?

Dovolím si kacířskou myšlenku: neměla by se právě na tyto uživatele spíš zaměřit osvěta, která by jim vysvětlila, co je to package management a k čemu je dobrý, místo toho, aby se vytvářely mezivrstvy, které jim budou předstírat, že Linux jsou vlastně Windows v jiném balení?

[Michal Vyskočil]

Zase tak kacířská není. Proč ne? Mě se takový přístup líbí, jenže s Linuxem je problém, že je pořád směřován pro geeky a ti také píší návody pro něj - viz naše vaše učebnice na ábíčku, viz neustále protěžovaná kompilace a to, jak jsou Xka skvělá a podobně. Samá konzole a kde se tam kliká? Což ovšem souvisí i s roztříštěností, distribucemi a tím, že Linux samotný je takový mlhavý a nic neříkající pojem (z hlediska marketingu, pochopitelně). U Windows je to jednodušší, to šedé jsou staré Windows, to zeleno modré jsou Ikspéčka a ty černé s průhlednými okýnky, to jsou ty super nové Visty.

Žel bohu, nevidím moc vůli po změně. Spíš dokonce odpor některých lidí k takovému směřování Linuxu.

[sprite]

Ja zrovna ted se snazim prejit z Win na Linux a musim ric , ze tech rozdilu je vic nez jsem cekal. Mam Suse a celkem muzu ric, ze se chova velmi dobre, ale prokousat se jinym zpusobem instalace po letech nepremysleni pri instalaci u Win je hruza. Jeste balicky ty jsou OK, ale ty bohuzel nejsou vzdy. Jasne instalace je urcite jednoducha, ale kdyz jste to nikdy nedelali tak je to docela problem.

[happy barney]

hmm, o niečo podobné sa zatiaľ snažím aj ja, mojím cieľom je však dostať sa pod distribúcie, kde by existoval napr bundle balík "slackware 11.0".

Zatiaľ si to komplikujem rôznymi požiadavkami typu dvojitá konfigurácia (package + system) a podobne.

[Bluebear]

O tomto tématu se nedávno vedly poměrně rozsáhlé spory na mailinglistu skupiny Linux Standard Base při Free Standards Group. V případě zájmu doporučuji nasísnout zde.

Některá navrhovaná řešení byla dost radikální, jako dva nezávislé package managery (jeden pro systém, druhý pro aplikace, aby ten pro aplikace mohl být nezávislý na distribuci), nebo vytvoření jednotného API, ke kterému by pak mohly přistupovat instalační programy, které si navrhne výrobce té které aplikace (vlastně ekvivalent windowsovských instalátorů). Velkou pozornost vzbudil taky Klik.

Pokud vím, zatím se ještě k definitivnímu řešení nedošlo, ale celá věc se bude probírat na nejbližším mítinku FSF v Berlíně 4. - 6. prosince.

[USAMA]

jo tak ty dva oddělené balíčkovací systém si myslím že by byl pro BFU jenom dobře. Možná bych poté i začal balíčkovací systém mít rád. ))

[thingie]

To není tak marné, mít dva různé balíčkovače. Ale nevím jestli by se to zvládlo.

[Michal Vyskočil]

Mrknu se

[Kníže Ignor]

Jeste v polovine textu jsem si myslel, zes mi ukradl napad. Ale ten muj je mnohem lepsi

[Michal Vyskočil]

Ten nápad jsem četl, ale tohle je prakticky to stejné, jenom zatím nevyžaduje podporu v prohlížečích

[ParadoX]

No, dneska jsem se setkal několikrát s tím že vidím program, vidím download, vyberu balíček pro mandrivu a po stažení otevřu. Systém se mě zeptá jestli chci instalovat -- ano, balíček byl nainstalová a mám ho -- nebo ne, chyba, nesplněné závislosti a jak na začátku zas jsem v řiti páč ani po hodině hledání jsem závislosti nenašel takže mám peška.

[USAMA]

Jako to si myslím že je vostrá aktivita! Konečně někdo začal taky myslet jako BFU!

[.....]

Jenže BFU přemýšlí jinak. Někde na síti si najde článek o nějakém super programu. Ihned se ho rozhodne vyzkoušet a první co uvidí je adresa ke stažení.

To jsem viděl nejen u BFU. Kamarád Windowsák si nainstaloval Ubuntu a takhle si tam přidal Operu. Naštěstí to šlo - stáhnul .deb a nainstaloval. Opravdový BFU si Linux nikdy nenainstaluje, protože o něm nepíší články o tom, jak si vytvořit šifrovanou složku atd. na Živě.

[Dalibor Smolík]

To jsem viděl nejen u BFU. Kamarád Windowsák si nainstaloval Ubuntu a takhle si tam přidal Operu. Naštěstí to šlo - stáhnul .deb a nainstaloval
Udělal snad něco špatně?

[Michal Vyskočil]

U Opery ne, ale jinde si stáhne max zdrojáky

[Filip Jirsák]

• package_name bych udělal dle konvence DNS nebo Java package jmen – jinak nastanou konflikty ve jménech
• počítal bych i s možností umístit popisný soubor na všeobecně známé místo v tar.bz2/tar.gz balíčku (třeba ./package.wbn) – pokud už si uživatel stáhne balíček se zdrojáky, může mu jeho správce souborů nebo manažer balíčků podle tohoto souboru pořád nabídnout správný způsob instalace
• verze bych vůbec neřešil, o to ať se postará manažer balíčků distribuce, musí mu stačit jméno – když instaluju přes distribuční manažer balíčků, také mu (obvykle) zadávám jen název balíčku, ne verzi
• přidal bych do popisného souboru možnost přidávat umístění repository balíčků a název balíčku v této repository pro různé distribuce – balíček nemusí být v oficiální repository distribuce a ta o něm nemusí nic vědět, ale distribuční manažer balíčků si zjistí, že třeba pro FC je repository na url té a té a balíček se tam jmenuje xyz
• aby na webové stránce bylo možné přidat <link href="amarok.wbn" type="application/wbn" rel="web-based-installer"> a prohlížeč s příslušným pluginem pozná, že ta stránka nabízí možnost instalace softwaru a nějakým způsobem to uživateli nabídne

[Michal Vyskočil]

Ta konvence pojmenování vypadá zajímavě. Takže něco jako org.kde.amarok? Dávat to do zdrojáků mě nenapadlo, ale proč ne. Ovšem s verzemi je nutné se nějakým způsobem poprat ... mělo by to dokázat i pracovat s vývojovou repository. S těmi neoficiálními repository to není špatný nápad, ale i proto se nedají verze změnit. Samozřejmě, integrace do prohlížečů je taky v plánu ...

Díky za nápady.

[Michal Vyskočil]

Ne změnit, ale odstranit ...

[Filip Jirsák]

Myslím, že BFU chce nainstalovat poslední stabilní verzi. Pokud chce někdo jinou verzi, měl by být na takové úrovni, že ví, že má používat distribučního správce balíčků a ví, jak ho používat. Alespoň tak chápu veškeré snahy o metabalíčkovací systém – že nenahrazují distribuční balíčkovací systém, ale "pouze" usnadní vyhledání programu a umožní uživateli nainstalovat jej správně nebo mu klidně jen řeknou, jak to správně udělat. Ze stejného důvodu bych neřešil ani update či odinstalaci balíčku.

[Michal Vyskočil]

Já tomu rozumím, ale v momentě, kdy bude v popisném balíčku uvedena i další repository (př. kubuntu.org/packages/amarok-latest), jak jsi navrhoval, mělo by být možné se nějak rozhodnout mezi instalací této, nebo oficiální stabilní verze. Takže se s těmi verzemi budu muset nějak vypořádat v každém případě.

Můj návrh je ten, že bude zvolen výchozí způsob (třeba instaluj stable) s tím, že si uživatel někde v pokročilých možnostech bude moci vybrat i jinou možnost.

[Filip Jirsák]

Aha, bral jsem alternativní repository jako variantu pouze pro případ, že balíček není v oficiální distribuční repository, jinak by měla mít distribuční repository přednost. Ale sám používám Gentoo jen s distribučními ebuildy, takže nevím, jak moc obvyklé je v jiných distribucích používat alternativní repository nebo alternativní balíčky a co to vlastně obnáší

[Michal Vyskočil]

Uvidíme, zkusím ty podněty nějak zpracovat. Rozhodně díky za zájem ...

[unknown_]

To s těma verzema, pokud by už byla nainstalovaná aplikace, tak by to upozornilo a pokud by instalovaný balíček byl v jiné verzi, tak by to upozornilo. Třeba "Vámi požadovaná aplikace již je nainstalovaná ve verzi XX.XX a vy si přejete nainstalovat STARŠÍ/NOVĚJŠÍ verzi YY.YY. Určitě?"

[zde]

aby na webové stránce bylo možné přidat <link href="amarok.wbn" type="application/wbn" rel="web-based-installer"> a prohlížeč s příslušným pluginem pozná, že ta stránka nabízí možnost instalace softwaru a nějakým způsobem to uživateli nabídne

Proč to komplikovat? <link href="amarok.sh" rel="installer"> je mnohem jednodušší.. Na nějaké XML bych se vykašlal.. Ten skript by jednoduše za runtime pomocí různých uname -sr; test -x /usr/bin/{yum|apt-get|pacman|..} zjistil na čem běží, přidal správná repository do správných konfiguráků, a spustil správný balíčkovač se správnými argumenty. Ad bezpečnost: BFU je to jedno, lepší uživatel se na ten skript nejdřív koukne (beztak se jen v prvním řádku nastaví jméno package, zbytek bude identický). A ruku na srdce, kdo kontroluje při dnešních zaneřáděných Makefiles, co mu se systémem vyvede sudo make install?

[Filip Jirsák]

aby na webové stránce bylo možné přidat <link href="amarok.wbn" type="application/wbn" rel="web-based-installer"> a prohlížeč s příslušným pluginem pozná, že ta stránka nabízí možnost instalace softwaru a nějakým způsobem to uživateli nabídne

Proč to komplikovat? <link href="amarok.sh" rel="installer"> je mnohem jednodušší.. Na nějaké XML bych se vykašlal.. Ten skript by jednoduše za runtime pomocí různých uname -sr; test -x /usr/bin/{yum|apt-get|pacman|..} zjistil na čem běží, přidal správná repository do správných konfiguráků, a spustil správný balíčkovač se správnými argumenty. Ad bezpečnost: BFU je to jedno, lepší uživatel se na ten skript nejdřív koukne (beztak se jen v prvním řádku nastaví jméno package, zbytek bude identický). A ruku na srdce, kdo kontroluje při dnešních zaneřáděných Makefiles, co mu se systémem vyvede sudo make install?

A proč to komplikovat? Proč kopírovat do tisíců skriptů stejné testy na zjištění distribuce a udržovat je aktuální, když můžu naopak distribučnímu správci balíčků předhodit informaci o tom, co jsem zač, pod jakým jménem mne zná a případně kde mne najde, a on už se postará o zbytek?

[Michal Vyskočil]

Nelíbí se mi to. Minimálně i proto, že se bude v každém skriptu dělat více méně to stejné. Jak jsem nad tím přemýšlel, mělo by to být pro autory sw co nejjednodušší.

XML také dvakrát nemusím, ale pro web je to nativní formát a umí s tím pracovat prakticky kdokoliv.

[zde]

Tohle je nevíce winodze-like (stáhne se executable a ten se spustí), takže BFU friendly. Redundanci obejít nelze, každý jiný systém by se stejně musel nejdřív bootstrapovat (instalovat pluginy do browseru, nebo nějak owrapovat nativní balíčkovač). A detekce (řekněme 4-5 hlavních) distribuce je jen pár desítek řádek kódu, to by mi nevadilo. Akorát to připomíná ten neskutečně hnusnej autoconf :(

[fakenickname]

Něco zajímavého na tom je, ale podle mne je prostě "hloupost bojovat s hloupostí". Pokud je někdo tak hloupý a nepřečte si základní instalační a administrační manuály k operačnímu systému tak je jeho problém, když si to roze*ere. Raději než obcházení lidské blbosti bych uvítal důslednější vštěpování filozofie instalace software v GNU/Linux-ových systémech. Vždyť je to přeci tak krásně navržené.. :(((

[Michal Vyskočil]

Byl bych opatrný nazývat dejme tomu špičkového chirurga jako hlupáka jenom proto, že se mu nechce číst manuál, aby si nainstaloval nějaký program. A navržené to zase tak hezky není, viz ty potíže s tím, na co se má sakra vlastně odkazovat, když už o nějakém kousku software píšu.

[Michal Kubeček]

Právě špičkový chirurg by měl IMHO lépe než kdo jiný chápat, že stejně jako je hloupost, aby jeho přítel systémák sám operoval manželce kýlu, je stejná hloupost, aby se on vrtal v systému, kterému nerozumí. Jen ty následky nejsou samozřejmě tak katastrofální…

[zde]

Raději než obcházení lidské blbosti bych uvítal důslednější vštěpování filozofie instalace software v GNU/Linux-ových systémech

Kterých systémech? Linux má minimálně 5 (ale spíš jich bude přes 10) naprosto nekompatibilních balíčkovacích systémů, různý systém updatů, různá členění repozitářů, různé systémy podepisování balíčků, různé způsoby reprezentace závislostí.. Pokud chcete udělat "neutrální" release, který z nich popíšete?

[XMurder]

Já mám tento nápad na manažera:
1. BFU si stáhne archiv se zdrojáky (tar.gz...)
2. Dvakrát klikne
3. Zobrazí se výzva s možnosti nastavení (info vytáhne ve většině případů z configure a MAKEFILE)
4. Tento inteligentní manažer mu to zkompiluje, vytvoří balíček (.deb), balíček nainstaluje, a doinstaluje závislosti z repozitářů (nebo jestě lépe pomocí síťově updatovanými kouzly stáhne závislosti z mateřškých webů (+ provede bod 4.) - jako u SourceMage).

[s0]

Já mám tento nápad na manažera:

1. BFU si stáhne archiv se zdrojáky (tar.gz...)

2. Dvakrát klikne

3. Tento inteligentní manažer mu najde balík v repozitářích jeho distra a ten nainstaluje.

[Petr]

A já mám tento nápad na NE_manažera:

Stáhnu archiv tar.gz.zip.blabla. Ten rozbalím a nakopíruju to kam potřebuju no a jenom spustím. Vyhledávám programy se kterýmy to takhle jde bez instalace jak na Linuxu tak na Windows a jsem docela spokojený.

[Filip Jirsák]

Ještě to budete chvilku vylepšovat, a až to bude použitelné, vylezou vám z toho Gentoo ebuildy… Schválně si někdy nějaký prohlédněte, ať vidíte, co znamená mu to zkompiluje…

[Michal Vyskočil]

Kompilaci uvažuji, ale nikdy nad úroveň zdrojových balíčků distribuce. Gentoo jsem používal, díval jsem se i na spelly a rozhodně to není nic, co bych vůbec chtěl řešit

[Jan Drábek]

mě napadá udělat jen nějaký plugin který najde vhodný yum, apt, emerge a na stránce v určeném bloku kódu zkusí vyhledat klíčové slovo v repozitářích.

[petr_p]

Vas postup predpoklada, ze distributor bude prohledavat vsechny mozne neoficialni repozitare pro jeho distribuci, aby mohl vybudovat vseobjimajici databazi balicku pro svoje distro. Jenze to je presne to, co distributor nikdy delat nebude. Pro nej konci svet oficialnim repozitarem (skladistem?).

Pokud to ale nebude delat distributor, bude to delat vyvojar? Nebude. Vyvojare nejvysse tak zajima distribuce, kterou on pouziva, jine mu jsou ukradane. Takze ten to taky delat nebude.

Podle mne tohle delat nebude nikdo. Takze resit alternativni repozitories nema smysl.

Podle mne staci, aby vyvojar urcil identifikator programu, ten se predhodi meta instalacnimu systemu, ktery jen zavola distribucne zavisly backend, ktery bude spravovat distributor a ktery vyhleda prislusny balicek a nabidne instalaci nativnimi prostredky dane distribuce.

Takovy identifikator by klidne mohlo byt URL domovske stranky programu. Vzhledem k tomu, ze tuto informaci obsahuji balicky vetsiny balickovacich systemu, tak by stacilo udelat index podle teto polozky.

[Michal Vyskočil]

Vas postup predpoklada, ze distributor bude prohledavat vsechny mozne neoficialni repozitare pro jeho distribuci, aby mohl vybudovat vseobjimajici databazi balicku pro svoje distro. Jenze to je presne to, co distributor nikdy delat nebude. Pro nej konci svet oficialnim repozitarem (skladistem?).

Rozhodně budu svůj postup konzultovat s lidmi, co se motají kolem distribucí. Přiznám se, že konkrétní způsob řešení neoficiálních repo neznám. Na druhou stranu o nich někdo vědět musí.

Podle mne tohle delat nebude nikdo. Takze resit alternativni repozitories nema smysl.

Správci alternativních repository toto mohou vyřešit. Ovšem je fakt, že je nutné jim ...

Takovy identifikator by klidne mohlo byt URL domovske stranky programu.

... co nejvíce ulehčit (to znamená nepřidávat) práci a identifikace podle URL je skvělý nápad! Díky

[Max]

Díra do systému, takto lze jednoduše podvrhnout balíčky a BFU si do PC nainstaluje každou kravinu, červ nečerv. Navíc hrozí podvržení adresy a mnoho jiných :(. Spoláhat se na webový browser? Hmm, né, díky ...
Zdar Max
PS: jsem pro sjednocení balíčkovacích systémů, nebo nějaké univerzální nadstavby nad všechny, ale nic takto extrémního bych nedoporučoval :-/