Unity portováno na Fedoru

OMG! Ubuntu! informuje o tom, že uživatelské rozhraní Unity, speciálně vytvořené pro Ubuntu, bylo pomocí openSUSE Build Service portováno na Fedoru. K dispozici jsou balíčky pro Fedoru 17.

20.7.2012 14:08 | Ladislav Hagara | Komunita

Komentáře

[xvasek]

Tak to bude trhák.

[l4m4]

To zaručeně. Jestli mi ve Fedoře něco chybělo, tak Unity...

[kavol]

OBS je zlo, zlo, zlo ...

[Martin]

Proc ? Me se s OBS pracuje celkem dobre. :)

[kavol]

třeba protože když se v tom někomu podaří zbuildit nějaký balíček, tak si myslí, že má tou kupkou hnoje, co mu z OBS vylezla, navždy vyřešenou podporu pro Fedoru

[pavlix]

Podle mě je celkem pochopitelné, když Ubunťáci buildují pro Fedoru v OBS. Pokud má někdo zájem, není problém danou věc zabalit do Fedory a balíčkem OBS se v horším případě jen inspirovat.

[kavol]

Podle mě je celkem pochopitelné, když Ubunťáci buildují pro Fedoru v OBS.

no, tož pro mě je to naopak první věc, kterou nechápu ... proč by probůh někdo z Ubuntu měl ztrácet čas děláním čehokoliv pro Fedoru?

[pavlix]

no, tož pro mě je to naopak první věc, kterou nechápu ... proč by probůh někdo z Ubuntu měl ztrácet čas děláním čehokoliv pro Fedoru?

Pak nezbývá než jim poděkovat, že se tak zajímají :).

[kavol]

za prvé, nechápu, jak tvůj výrok odpovídá na můj dotaz, tedy proč tady takto a ještě s citací reaguješ

za druhé, ne, opravdu nebudu děkovat někomu za to, že dělá bordel v distru

za třetí, ten problém jde dál než jen k možným uživatelským potížím s tím či oním balíčkem, za tím je pak neochota udržovat balíček pořádně a někdy i neochota upstreamu bavit se s tím, kdo to udržovat pořadně chce a chce to dostat do Fedory - vždyť přece balíček v OBS existuje, tak co kdo otravuje s nesmyslama, že by se neměly natvrdo bundlovat knihovny, který už v systému jsou apod.

[pavlix]

za druhé, ne, opravdu nebudu děkovat někomu za to, že dělá bordel v distru

Jak prosím dělají bordel v distru tím, že si na svém písečku vybuildují nějaké RPM?

neochota upstreamu bavit se s tím, kdo to udržovat pořadně chce a chce to dostat do Fedory

Neochota upstreamu je problém sám o sobě, IMO na tom tohle už nic nezmění.

vždyť přece balíček v OBS existuje, tak co kdo otravuje s nesmyslama, že by se neměly natvrdo bundlovat knihovny, který už v systému jsou apod.

Vem si třeba freeswitch. Budu rád, když někdo bude udržovat kvalitní balík freeswitche, přesto vím, není možné ho zařadit do fedory a není možné přesvědčit upstream, aby přestal bundlovat desítky knihoven.

Mají k tomu své důvody, proč to tak dělají, a pokud se nenajde někdo, kdo by byl ochotný klíčové věci z jednotlivých knihoven jednu po druhé upstreamovat, následně ten software portovat na aktuální verze knihoven (s už upstreamovanými změnami), a ještě se starat o komunikaci s dalšími projekty, aby k potřebě bundlování znovu nedošlo, máš prostě smůlu.

[kavol]

za druhé, ne, opravdu nebudu děkovat někomu za to, že dělá bordel v distru

Jak prosím dělají bordel v distru tím, že si na svém písečku vybuildují nějaké RPM?

to rpm si pak například uživatelé instalují, a stěžují si na problémy jím způsobené a chtějí, aby je řešili vývojáři Fedory ...

neochota upstreamu bavit se s tím, kdo to udržovat pořadně chce a chce to dostat do Fedory

Neochota upstreamu je problém sám o sobě,

to sice ano, ale ...

IMO na tom tohle už nic nezmění.

... tohle jim dává možnost říct "tady máte balík a neotravujte", čili již tak nízkou motivaci to ještě snižuje

Vem si třeba freeswitch. Budu rád, když někdo bude udržovat kvalitní balík freeswitche, přesto vím, není možné ho zařadit do fedory

hm, a OBS je jediná cesta, neexistují žádné repozitáře určené pro balíčky, které z nějakého důvodu do Fedory jít nemůžou ...

a není možné přesvědčit upstream, aby přestal bundlovat desítky knihoven.

Mají k tomu své důvody, proč to tak dělají, a pokud se nenajde někdo, kdo by byl ochotný klíčové věci z jednotlivých knihoven jednu po druhé upstreamovat, následně ten software portovat na aktuální verze knihoven (s už upstreamovanými změnami), a ještě se starat o komunikaci s dalšími projekty, aby k potřebě bundlování znovu nedošlo, máš prostě smůlu.

ale nepovídej, je to přeci opensource, přeci máš možnost si ten kód pročistit jak potřebuješ

[pavlix]

to rpm si pak například uživatelé instalují, a stěžují si na problémy jím způsobené a chtějí, aby je řešili vývojáři Fedory ...

Na to mám jedinou odpověď. Nasrat.

... tohle jim dává možnost říct "tady máte balík a neotravujte", čili již tak nízkou motivaci to ještě snižuje

Má to své pro a proti.

hm, a OBS je jediná cesta, neexistují žádné repozitáře určené pro balíčky, které z nějakého důvodu do Fedory jít nemůžou ...

Kdo tvrdí, že OBS je jediná možnost, jak vytvořit repozitář? Ale je to docela hezká možnost (z hlediska tvůrce vícedistribučního balíku), pracoval jsem s tím na MeeGo.

ale nepovídej, je to přeci opensource, přeci máš možnost si ten kód pročistit jak potřebuješ

Kdybys četl to, na co reaguješ, zjistil bys, že tvá reakce je tam už obsažena.

[kavol]

to rpm si pak například uživatelé instalují, a stěžují si na problémy jím způsobené a chtějí, aby je řešili vývojáři Fedory ...

Na to mám jedinou odpověď. Nasrat.

bohužel, tato odpověď nezavře automaticky takové bugreporty a nevylepší špatné PR, které tak Fedora získá

hm, a OBS je jediná cesta, neexistují žádné repozitáře určené pro balíčky, které z nějakého důvodu do Fedory jít nemůžou ...

Kdo tvrdí, že OBS je jediná možnost, jak vytvořit repozitář?

tam patřil otazník

pokud jediná není, proč se k tomu tedy takto stavět? - vyjma následujícího:

Ale je to docela hezká možnost (z hlediska tvůrce vícedistribučního balíku), pracoval jsem s tím na MeeGo.

jenže hledisko "tvůrce vícedistribučního balíku" je jen jedno z mnoha, a to dokonce jedno z těch nejméně významných, viz výše

ale nepovídej, je to přeci opensource, přeci máš možnost si ten kód pročistit jak potřebuješ

Kdybys četl to, na co reaguješ, zjistil bys, že tvá reakce je tam už obsažena.

kdybys věděl, co jsi napsal, tak bys zjistil, že není - ty tvrdíš, že "... máš prostě smůlu"

já říkám, že nemáš, můžeš s tím přece něco dělat

[little.owl]

bohužel, tato odpověď nezavře automaticky takové bugreporty a nevylepší špatné PR, které tak Fedora získá

Tohle jsou hodne validni body, ktere jsem si neuvedomil.

Otazka zni spise: "Proc lide pouzivaji baliky z OBS?" a jestli je mozne jejim duvodum vyjit nejak vstric. Pokud je duvodem, ze do OBS muzete dat kazdou sracku bez QA, pak jsem rad, ze to je jak to je.

[David Jaša]

bohužel, tato odpověď nezavře automaticky takové bugreporty a nevylepší špatné PR, které tak Fedora získá

Fedoří abrt nezahazuje crash reporty programů z nefedořích repozitářů?

[kavol]

nevim, jaký je aktuální stav, ale posledně mi to nezahodil, akorát to selhalo, že nenašel komponentu (a nenechal si ručne vnutit, že to chci v jiným produktu; tuším, že na to jsem dokonce reportil RFE) ... krom toho, měl by si nechat zkonfigurovat, kam to chceš hlásit (já bych třebas cpal něco do bugzilly RPMFusion); ostatně defaultní target je logger, tam je už úplně jedno, co ti spadlo, když si to řešíš lokálně

jinak ne všechny bugy jdou přes abrt - ne všechno končí přímo pádem

---

Fedora má poměrně striktní pravidla na balíčkování, který se ledaskomu zdaj jako buzerace, takže se radši obrátí na OBS, kde je pravidlo jediný - že to jde nějak zbuildit

jenže ony ty pravidla dávaj docela dobrej smysl, předcházej spoustě věcí, který nejsou vidět na první pohled; proto jiný repa (mluvim za RPMFusion, kam jsem přišel z Livny, nemůžu strkat ruku do ohně za ostatní) tyto pravidla přebíraj vpodstatě komplet (RPMFusion má vlastní politiku ohledně jadernejch modulů, v tom dolňuje Fedoru, která externí moduly zakazuje, no a pak samozřejmě řeší jinak licence a exportní politiky USA)

a když to u něčeho fakt nejde (nebo nedává smysl), tak si lze zažádat o vyjímku - samozřejmě pokud důvodem je, že upstream prasí, a balíčkovač by se z toho zbláznil mít to dostávat do formy, tak se vyjímka nejspíš neschválí, o takovej upstream nestojíme ... v Pavlixově příkladu, nikdo nebude řešit bezpečnostní problém v pět let starý verzi bundlovaný knihovny, když je v distru verze aktuální, neděravá; na druhou stranu, když je to třeba jen jedna knihovna, která samostatně zabalená není, nikdo jinej jí nepoužívá a třeba navíc upstream knihovny nevydal stabilní verzi už léta zatímco závislej projekt staví na novější verzi z VCS a sám se o její patchování stará, tak je schválení vyjímky téměř jistý

[kouzer]

Proč?!?

[Rezza]

Doufam, ze budeme mit OBS like system ve Fedore jednou taky. Zvlast na podobne veci, ktere nejsou jednoduse zabalitelne do hlavniho repozitare. Maji tam trebas i vlastni gcc 4.6, protoze jim to zatim nepreklada s 4.7 (zmeny jsou, ale minimalni). Je potreba osekat patche a vypada to, ze se i celkem Gnomaci s Unitarama zacali bavit. Takze to pujde. Je tam jeste kupa zavislosti - jejich touch framework. Compiz je ve Fedore mrtvy... Proste prvni krok je to dobry. Ceka je jeste fura, ale...

[pavlix]

Hmm, tak to zní dobře.

[little.owl]

Doufam, ze budeme mit OBS like system ve Fedore jednou taky.

+1

Je potreba osekat patche ... Je tam jeste kupa zavislost ... Compiz je ve Fedore mrtvy...

Radsi bych mel ve Fedore Cinnamon v hlavnim repositari, nez se trapit s Unity.

[w4rr10r]

Mám pocit, že jsem včera zahlédl v r/linux odkaz na nějaké oznámení Cinnamonu pro Fedoru.

[kavol]

Doufam, ze budeme mit OBS like system ve Fedore jednou taky. Zvlast na podobne veci, ktere nejsou jednoduse zabalitelne do hlavniho repozitare.

free builder pro Fedoru? - good idea

free builder pro "všechny"? - viz výše

[Petr Tomášek]

Nemůžeš mluvit nějakým srozumitelným nářečím?

[MeeGo - no future]

Tak a teď přišel Canonical o svoje největší eso v rukávu. Jediné, co je může zachránit od masivního odlivu uživatelů, je příchod Steamu jakož i AAA titulů v něm distribuovaných :D

[lenny]

o tom pochybujem comu das prednost?

1) Unity s apt-getom

alebo

2) Unity s Yumom.. ak mam robit s yumom tak ani za trest

sem tam skusam Fedoru s XFCE ale vzdy ma odradi ten divnej balickovac

:D

[michi]

Ámen.

[l4m4]

Neboj, ve F18 bude k disposici ještě divnější balíčkovač (DNF). yum v podstatě normálně funguje...

[little.owl]

divnější balíčkovač (DNF)

O DNF nemam dost informaci, kde je mozne je nalezt, aby si clovek mohl ucinit zaver?

[David Jaša]

https://fedoraproject.org/wiki/Features/DNF

[little.owl]

A v cem je tak zasadni rozdil mezi apt/aptitude/dselect/* + deb a yum + rpm ? Rychlost yum-u je uz nyni dostatecna a velky pokrok pri updatech jsou delta RPM, ktere vam redukuji downloady o desitky %.

[petr_p]

Hádat můžeš třikrát: yum install NĚCO_S_MNOHA_ZÁVILOSTMI; yum remove TO_SAMÉ. Tohle není balíčkovací systém, to je Slackware. O nemožnosti downgradovat včetně reverzních závislostí nemluvě. (Neříkejte o tom Lennartovi :)

[David Jaša]

Ten flag o manuálním/automatickém "původu" balíků se prý bude dodělávat, bohužel však na úrovni yum/DNF a ne rpm(db), kam by to mělo logicky patřit.

[pavlix]

Mimochodem oni se teď Debianisti honosí tím, že se jim povedlo částečně implementovat, to co mělo Gentoo roky a správně. Já budu taky rád, když to propluje do RPM světa a radši bych, kdyby to bylo na úrovni RPM, ale dělat z toho nějakou ctnost Debianu mi přijde mimo.

[David Jaša]

Mimochodem oni se teď Debianisti honosí tím, že se jim povedlo částečně implementovat ... ale dělat z toho nějakou ctnost Debianu mi přijde mimo.

Debian to měl bezproblémově a plně funkční už v době, kdy na RHL byl k dispozici tak akorát up2date, tudíž nevidím nic špatného na tom, když se z toho dělá ctnost. Ono je možný, že to třeba apt-get nebo dselect neměl naimplementováno správně, nicméně aptitude to správně měla.

[pavlix]

Debian to měl bezproblémově a plně funkční už v době

Asi mám trošku jinou představu o „bezproblémově a plně funkční“, když jsem se víc zabýval debianem, tak to ještě neměli vůbec, a později to dolepili nějak divně, že se to týkalo jen některých balíků.

A nesrovnávám s RHL, ale s Gentoo.

[David Jaša]

Gentoo osobně neznám a tudíž se k němu nevyjadřuju a předchozí konverzace se točila okolo (redhatího) RPM, kde v té době teprve přišli na to, že by to nějakou nadstavbu přeci jen chtělo. Jinak jsem si opravdu nevšiml, že by to v Debianu "neměli vůbec" nebo že by to bylo "divně dolepené", tedy alespoň od přelomu 2004/2005, kdy jsem to začal používat.

[pavlix]

Jo jenže ses opřel do mého srovnání s Gentoo. Já bohužel nemám informace o aktuálním vývoji Debianu, ale popíšu ti alespoň fungování Gentoo.

Když dáš v Gentoo nainstalovat jakýkoli balíček, poznamená si Gentoo, že jsi ten balíček chtěl. Nainstaluje ti závislosti, ale u nich si tento příznak nepoznačí.

Ve chvíli, kdy dáš balíček odinstalovat, tak Gentoo funguje jako většina distribucí, tedy odinstaluje pouze ten jeden balíček. Ale máš k dispozici příkaz, který vykope všechno, co je v systému pouze jako závislost.

Protože je to source distro, tak máš ještě příkaz, který projede celý systém, jestli se tím něco nerozbilo, ale to bys u binárek nepotřeboval.

Neříkám, že na tom nejde dál stavět a vylepšovat, ale nemám informace o tom, že by binární distribuce běžně nabízely možnost vykopat ze systému vše, o co jsem si neřekl.

[David Jaša]

Když dáš v Gentoo nainstalovat jakýkoli balíček, poznamená si Gentoo, že jsi ten balíček chtěl. Nainstaluje ti závislosti, ale u nich si tento příznak nepoznačí.

U Debianu je ten příznak obráceně - 1 pokud balíček nebyl explicitně nainstalován uživatelem.

Ve chvíli, kdy dáš balíček odinstalovat, tak Gentoo funguje jako většina distribucí, tedy odinstaluje pouze ten jeden balíček. Ale máš k dispozici příkaz, který vykope všechno, co je v systému pouze jako závislost.

Debian se při jakékoliv změně balíčků podívá do databáze a odinstaluje všechny automaticky instalované balíčky, které už nemá žádný ručně instalovaný balíček nechce.

Neříkám, že na tom nejde dál stavět a vylepšovat, ale nemám informace o tom, že by binární distribuce běžně nabízely možnost vykopat ze systému vše, o co jsem si neřekl.

Tak Debian a odvozeniny to fakt mají snad od minulého tisíciletí. Tedy s jednou drobností: debianí odinstalace standardně nevykope ze systému všechno, ponechá na disku konfiguraci a uživatelská data - nicméně je asi tak na pět sekund aptitude říct, aby ty balíčky vykopala úplně.

[pavlix]

U Debianu je ten příznak obráceně - 1 pokud balíček nebyl explicitně nainstalován uživatelem.

Na tom by až tak nezáleželo. Ale aby to mělo smysl, tak by to neměly nástroje nikdy obcházet, tedy ideálně by to měl dělat Deb.

Faktem je, že v době, kdy jsem Debian nejvíc řešil, tak tohle vůbec neměl.

Debian se při jakékoliv změně balíčků podívá do databáze a odinstaluje všechny automaticky instalované balíčky, které už nemá žádný ručně instalovaný balíček nechce.

To zní rozumně, ale rád bych nějaký relevantní zdroj.

Tak Debian a odvozeniny to fakt mají snad od minulého tisíciletí.

Byla doba, kdy jsem to zjišťoval i někde po mailing listech snad. Takže opět prosím zdroj i ohledně toho, kdy tahle feature byla k dispozici a který software ji zajišťoval.

ponechá na disku konfiguraci a uživatelská data - nicméně je asi tak na pět sekund aptitude říct, aby ty balíčky vykopala úplně.

Tak na to jsem ale hodně zvědavý. Představ si, že jsem odinstaloval balíček A a B. Díky tomu přestaly být potřeba balíčky C, D, E, F, G, H a X. A teď držím v hlavě akorát A a B. Jakým způsobem, že to vykopu veškerou konfiguraci ke všem těmto balíkům?

[Spike]

apt-get/aptitude autoremove odstraní nepotřebné balíky, které byly dotažené jako závislost.

[Spike]

A tady máš příklad, jak smazat i tu konfiguraci. Ale pravda, používá to dpkg a není to už zrovna pohodlně vestavěná funkce.

[pavlix]

Tak něco málo je tu:

http://go2linux.garron.me/apt-get_and_aptitude

[pavlix]

Jo, pěkné. Ještě je co dotahovat. Btw, existuje něco jako emerge --oneshot?

[petr_p]

aptitude má příkaz pro přepnutí příznaku automatické instalace již nainstalovaného balíku. Myslím, že ale před pár lety neměl žádný přepínač pro vynucení příznaku již při instalaci.

[pavlix]

Teď zrovna David Jaša víceméně tvrdil, že nic takového není potřeba a že se balíky odstraňují automaticky.

[pavlix]

GOTO 49, nějak se mi porušila návaznost komentářů

[David Jaša]

GOTO #40, poslední věta.

[little.owl]

bohužel však na úrovni yum/DNF a ne rpm(db),

To by davalo smysl pokud by tam byl nejaky dlouhodoby plan zrusit RPM.

[David Jaša]

Proč by mělo rozšíření or rpmdb o nějaký příznak znamenat zrušení RPM?

[David Jaša]

s/or //

[pavlix]

Přesně naopak :).

[little.owl]

Po zkusenostech Mandriva s RPM5 je snad mozna lepsi to nechat byt a postupne paralellne prejit na nejaky novy system.

[David Jaša]

Tak RPM má spoustu kostlivců ve skříni, ale v zásadě funguje. Proto mi přijde zaměření fedořích vývojářů na vyšší vrstvy v pořádku, ale opravdu nechápu, proč by se měly držet na disku dvě databáze spravované dvěma nástroji místo jedné jediné (a proč by jejich sloučení do rpmdb mělo znamenat konec RPM).

[little.owl]

Tak RPM má spoustu kostlivců ve skříni, ale v zásadě funguje.

+1

[petr_p]

Zdroj? Když jsem naposledy mluvil s Adamem, tak mi to vyvrátil.

[David Jaša]

IIRC mi to říkal Aleš. Pokud to tak nebude, bude to jedině dobře.

[lennart]

uz zas mi zatajujes

[pavlix]

3) Yum bez Unity.

Jako uživateli je mi jedno, jestli píšu yum install nebo aptitude install nebo apt-get install. Na druhou stranu, jako tvůrci balíčku mi vyhovuje napsat jednoduchý RPM specfile (či ebuild či jinou smysluplnou alternativu) než se patlat s debianími balíky.

[little.owl]

+1

[Dreit]

http://www.youtube.com/watch?v=blVEC0ERdnE Tady se bez Unity instaluje jako o život

[2X4B-523P]

si sám patlám deb balíky a přijde mi to dost jednoduché, jednodušší už by bylo jen ten balík nijak nepopsat a nevyplnit mu závislosti, což bude asi tvorba rpm, když je tam jednoduchý "specfile"

[little.owl]

Potreboval jsem modifikovat nekolik baliku se stejnym SW pro SUSE a Debian, tedy upravit originalni zdrojove zdrojove kody a opet zbuildovat baliky s novou revizi.

V pripade SUSE to bylo jednodussi, instalace rpmbuild, stahne se jeden RPMS balik (~= normalni RPM balicek), lokalne instaluje, vygeneruje jeden patch file, upravi jeden SPEC file a jednim prikazem se opet vytvori najednou zdrojovy balicek RPMS a prislusne binarni RPM.

V pripade Debianu to bylo slozitejsi, musel jsem nainstalovat nikoliv jeden, ale kupu nastroju a nastavovat pro ne environment variables, zadny ekvivalent jednoho zdrojoveho RPMS baliku, baliky pouzivali vice formatu - quilt a patchsys - kolik ze Debian ma patch systemu?, musel jsem modifikovat nekolik souboru u kazdeho baliku a vysledkem byla binarka a nekolik novych zdrojovych souboru pro kazdy balik, nehlede k tomu ze Debian rad rozdeluje SW na male baliky a je jich pak vice.

Moje pocity jsou stejne jako pavlix-ovi a to presto, ze RPM ma velmi temne stranky.

[pavlix]

Tak což o to, na tvorbu patchů můžeš všude používat různé patch systémy, ne?

[little.owl]

Na tvorbu ano; u Debianu jsou soucasti formatu pro vytvareni balicku a pouziva se jich na muj vkus trochu moc: dpatch, quilt, simple-patchsys, dbs, git ... kazdy ma sve limitace a vliv na to jak vypadaji skripty v rules a kdyz se to upravuje musi se s tim pocitat. Koukam ze novy "3.0 (quilt)" ma uz navrch a asi bude dominovat (+1); nicmene zlaty %patch.

[pavlix]

Nevím, u RPM nic takového neřeším a prostě to nechám patchnout, jak sám píšeš.

[pavlix]

Zajímavý myšlenkový proces. V případě RPM nebo Gentoo ebuildů je potřeba napsat jeden soubor, který neobsahuje prakticky žádné zbytečnosti (jen metainformace o balíku a instrukce pro jeho vytvoření). K tomu už potřebuješ jen zdrojáky a patche.

Díval jsem se do nějakých balíků, které jsou součástí Debianu a Ubuntu a i jsem to zkoušel, ale vůbec to nebylo tak, jak tvrdíš. Ve skutečnosti tam byla potřeba hromada souborů v adresáři debian.

Ale členění na více souborů bych jim ještě nevyčítal, i když mi přijde na tak jednoduchou úlohu blbost používat víc než jednoduchý specfile. Co mě zaráží víc, je kolik zbytečností v těch souborech ještě bylo, které specfile nebo ebuild vůbec nepotřebují a pochybuju, že je dokáže deb nějak zužitkovat. Měl jsem pocit, že tam jsou v balíčcích zopakovávané věci, které spíš patří do toho systému samotného a ne do každého balíku.

Když mi někdo vysvětlí, v čem je to lepší, a co tyhle komplikace oproti jednoduchému souboru s popisem buildu přinášejí, tak třeba změním názor.

[Bluebear]

Závidím předřečníkům schopnost chápat tak složité věci, jako RPM. Já, když sestavuju .spec file, trpím jako zvíře.

• Nikdy nevím, jaký je aktuální adresář, a nikdy nevím, jestli se daný .tar soubor rozbalí v aktuálním adresáři, o adresář výš nebo o adresář níž. (Totéž platí o patchích.)
• Nejsem schopen si zapamatovat názvy maker a jemné rozdíly v jejich významu, například v životě jsem nepochopil rozdíl mezi %buildroot% a $RPM_BUILD_ROOT a nikdy nevím, co udělá %setup -a a co %setup -b.
• Nikdy jsem nepochopil, proč se zdrojové soubory a patche číslují místo identifikátorů a jestli se číslují od nuly nebo od jedničky.
• Celá syntaxe mi připadá nekonzistentní a nezapamatovatelná (různé sekce mají zcela různý význam i pravidla syntaxe; některé proměnné se označují dolarem, jiné procentem); marka, která by teoreticky měla věc zhoršovat, jen přidávají další vrstvu totálního zmatku.

Nevylučuji, že debianí popis balíčků je ještě horší, ale to už musí být fakt peklo na zemi.

[little.owl]

Jak jsem psal, RPM ma velmi temne stranky a byl jsem jiz nucen koukat do kodu, abych pochopil jak funguje. Jestli je ale nejaky plan s tim neco delat, nevim.

[pavlix]

To nevylučuju. Ale 2X4B-523P to musí být hotové nebe, pokud by přistoupil na to, že je to jednodušší než Deb.

[little.owl]

On celkem presne vystihl slaba mista, proti tomu nelze nic namitnout. Pozadavek zpetne kompatibility v kombinaci s dedictvim Jeffa Johnsona, muze zpusobovat v urcitych situacich slusny bolehlav.

Ja jako smoula vytvarejici jednoduche balicky - .tar a par patchu - nemam zadny problem a jde to jak po masle, ale dokazi si predstavit ze zacinajici maintaineri vetsich baliku si to mohou uzit.

[pavlix]

Spletl sis postavy v diskuzi.

[pavlix]

Závidím předřečníkům schopnost chápat tak složité věci, jako RPM. Já, když sestavuju .spec file, trpím jako zvíře.

Po prvním balíčku pro Fedoru to už šlo samo. Pečlivě jsem si četl guidelines a další zdroje na wiki.

Nikdy nevím, jaký je aktuální adresář

Pro mě je to vždy ten, ve kterém se builduje. V sekci %prep všechno řeším příslušnými makry.

nikdy nevím, jestli se daný .tar soubor rozbalí v aktuálním adresáři, o adresář výš nebo o adresář níž. (Totéž platí o patchích.)

Source (tarball) mi rozbaluje %setup, patche mi aplikuje %patch, všechny další zdrojové soubory se mi objevují v pracovním adresáři.

Nejsem schopen si zapamatovat názvy maker a jemné rozdíly v jejich významu

Já si je nezapamatovávám, ale buď vycházím ze šablony (kupodivu mi ji i vim sám v nějaké nacpe do nového souboru .spec), nebo vezmu za šablonu svůj starší balík. Na zbytek používám wiki.

například v životě jsem nepochopil rozdíl mezi %buildroot% a $RPM_BUILD_ROOT

Jen v zápisu. Našel jsem to někde na wiki. Používám všude %{buildroot}.

nikdy nevím, co udělá %setup -a a co %setup -b.

Ani jedno nepoužívám. Rychle jsem to zadal do googlu a vypadlo mi, že je to k rozbalování dalších tarballů buď před nebo po přepnutí do build adresáře. Magie, které klidně deset minut věnuju, kdybych někdy potřeboval takový balík dělat.

(http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html)

Nikdy jsem nepochopil, proč se zdrojové soubory a patche číslují místo identifikátorů a jestli se číslují od nuly nebo od jedničky.

Já je čísluju od nuly a neřeším. U patchů je to zřejmě jedno. Makro %source tuším implicitně používá nulu.

Celá syntaxe mi připadá nekonzistentní a nezapamatovatelná (různé sekce mají zcela různý význam i pravidla syntaxe; některé proměnné se označují dolarem, jiné procentem);

Žádné dolarové proměnné kromě proměnných cyklů a $1 ve skriptletech nepoužívám.

Nevylučuji, že debianí popis balíčků je ještě horší, ale to už musí být fakt peklo na zemi.

Asi tak nějak.

[little.owl]

mezi %buildroot% a $RPM_BUILD_ROOT

Tusim, ze kdyz rpmbuild sklada sript pise:

RPM_BUILD_ROOT="%{buildroot}"

Rychle jsem to zadal do googlu a vypadlo mi, že je to k rozbalování dalších tarballů buď před nebo po přepnutí do build adresáře.

Ano. -a jako after, -b jako before a duvodem tusim bylo, ze nektere originalni .tar nejsou v adresari.

Vetsinu jeho nejasnosti by vyresilo desetiminutove hledani na netu.

[pavlix]

Vetsinu jeho nejasnosti by vyresilo desetiminutove hledani na netu.

Vlastnoručně ověřeno :).

[petr_p]

Vetsinu jeho nejasnosti by vyresilo desetiminutove hledani na netu.

Bohužel nic není na jednom místě. Něco je popsané na wiki RPM, něco v redhatí dokumentaci, něco jen v dokumentaci zdrojového archivu RPM, něco lze najít jen v Yetiho Rukověti baliče. A třeba filtrování závislostí podle RPM 4.9 jen jako jistý náčrt v mailing listu RPM.

Co bych dal za specifikaci, jako má Gentoo PMS.

[Michal Kubeček]

Nejsem schopen si zapamatovat názvy maker a jemné rozdíly v jejich významu, například v životě jsem nepochopil rozdíl mezi %buildroot% a $RPM_BUILD_ROOT … některé proměnné se označují dolarem, jiné procentem

Procento se používá pro makra, která se definují pomocí %define, a expanduje je samotný rpmbuild. To, co začíná dolarem, je prachobyčejná expanze proměnné prostředí a provádí ji shell, který je rpmbuildem spouštěn k provedení příkazů v jednotlivých sekcích.

[Michal Vyskočil]

Závidím předřečníkům schopnost chápat tak složité věci, jako RPM. Já, když sestavuju .spec file, trpím jako zvíře.

Ono rpm není ani tak složité, jak spíše šíleně nekonzistentní. Ty jeho makra versus proměnné, versus _makra a __makra (nebo %makeinstall, versus %make_install) jsou prostě jenom důsledek toho, jak je to celé zpanchartělé. Proto taky dobré balíčky dělají vesměs ti, co mohou udělat grep na zdrojový strom a podívat se, jak se ona věc řeší jinde.