Spuštěn web rpm5.org (diskuse)

[anicka]

Ooops. Rozumim tomu dobre, ze kdyz uz se nekdo konecne pustil do hackovani RPM, tak se bude radeji zabyvat implentaci podpory pro XAR, protoze XML je cool, namisto aby resil ty *skutecne* problemy?

Bylo by pekne, kdyby "obchazeni bugu v RPM" nebylo nutnou soucasti vzdelani kazdeho, kdo dela balicky...

[Aleš Kapica]

Raději vymýšlejí znova kolo, než by použili zaběhnuté a stabilní řešení..

[Qaxi]

Které ?

Pokud se vůbec budete namáhat odpovědět tak, prosím ještě uveďte výhody a nevýhody toho "zaběhnutého a stabilního" řešení.

Děkuji

[anicka]

Predpokladam, ze myslel APT (a popis vyhod a nevyhod necham na nem, jelikoz povidani o tom, co vsechno RPM neumi a mohlo by bylo na strasne dlouho), ale nedavno jsem se dozvedela o jedne dalsi, mozna jeste lepsi moznosti - Conary.

[Aleš Kapica]

Přesně tak. Myslel jsem APT. A pokud jde o nějaký popis výhod a nevýhod, tak se laskavě krapet namáhejte, můžete toho nalézt na netu celkem dost - i něco přímo ode mne.

[Yenya]

Tady je pekne videt jak nerozumite tematu

Apt neni analogie k RPM. Apt je analogie k up2date nebo yum. Muzeme se bavit ktery z nich je lepsi, ale s rpm5.org tohle nesouvisi.

Analogii k RPM je DEB, a to se snad vsichni shodneme, ze RPM toho umi daleko vice[*], ostatne taky proto RPM pouzivaji vsichni krome Debianu (Ubuntu = Debian), at uz nad tim maji jakoukoli nadstavbu.

[*] nebudu se opakovat, ale treba triggery, prefixy, automaticke generovani zavislosti na knihovnach ale i treba na Perlovych a jinych modulech, zavislosti pro rebuild baliku, ...

-Yenya, http://www.fi.muni.cz/~kas/blog/

[Aleš Kapica]

Bože já se snad umlátím smíchem.. APT a DEB patří nerozlučně k sobě. Na RPM jsem začínal a jedním z důvodů proč se mu vyhýbám jak čert kříži bylo právě to, že jsem se začal trochu víc zajímat o to co za tím je. Materiál max-rpm jste asi četl a znáte, nebo snad ne?

Analogii k RPM je DEB, a to se snad vsichni shodneme, ze RPM toho umi daleko vice[*], ostatne taky proto RPM pouzivaji vsichni krome Debianu (Ubuntu = Debian), at uz nad tim maji jakoukoli nadstavbu.

To opravdu nemyslíte vážně, že ne? Podíl RPM distribucí je parciální jak se ostatně můžete přesvědčit sám. Nebo mi snad chcete tvrdit, že i Gentoo, Arch, Slackware aj. rovněž používají RPM? Navíc co RPM distribuce, to nějaké vlastní udělátko které se nějakým způsobem snaží docílit téhož co umí APT.

APT to je pouhá sada utilit pro práci s balíky tzn. žádný up2date či yum.

Chápu že iniciativa rpm5 vzniká proto, protože se stávajícím formátem již prostě víc dělat nejde. Nicméně když má na to někdo chuť a nápady, proč ne.

Mimochodem. Věci které zmiňujete v posledním odstavci - tak na tohle už apt a Debian nástroje dávno má.

[Aleš Kapica]

A ještě poznámku. Vám opravdu nedochází proč u jedné z nejstarších distribucí již řadu let balíčkovací systém a jeho balíčkovací manažer nikdo neřeší? A i když jiné distribuce nenechají z původního Debianu téměř kámen na kameni, to co zůstává vždy je APT?

[michich]

APT to je pouhá sada utilit pro práci s balíky tzn. žádný up2date či yum.

Logika této věty mi uniká. yum teda není utilita pro práci s balíky?

Chápu že iniciativa rpm5 vzniká proto, protože se stávajícím formátem již prostě víc dělat nejde.

Ne, vzniká proto, že to chce Jeff Johnson. Nedá se říct, že by v tom panoval všeobecný souhlas.

Mimochodem. Věci které zmiňujete v posledním odstavci - tak na tohle už apt a Debian nástroje dávno má.

Jak tak lehce sleduju dění, vidím, že např. triggery jsou u dpkg teprve ve stadiu návrhu.

proč u jedné z nejstarších distribucí již řadu let balíčkovací systém a jeho balíčkovací manažer nikdo neřeší

Asi jste se špatně díval. Mám Debian rád, ale takhle růžová situace, jak ji líčíte, tam není.

[Aleš Kapica]

Ad logika věty. Přiznávám, že jsem ji napsal poněkud zašmodrchaně. Nicméně jsem jí chtěl říct, že APT není na rozdíl od yum žádná konkrétní aplikace, ale balík na sobě více či méně závislých aplikací které mají společné to že jsou určeny pro práci s DEB balíky. A v podstatě se dá říct, že k němu patří i jiné balíky. APT je systém práce s balíky, ne aplikace.

Pokud jde o líčení růžové situace. Nic takového jsem nepsal. Jen jsem uvedl, že otázka balíčkovacího systému je u Debianu považována za zcela okrajovou a stav za vyhovující, protože jsem za téměř tři roky co u mne Debian nahradil Mandrivu nezaznamenal, že by někdo žehral na nějaké nedostatky balíčkovacího systému DEB (což bohužel o RPM říct nelze).

Že jsou v APT i utility slabší kvality, o tom mi povídat nemusíte. Přinejmenším o jedné takové vím - dpkg-name, jsem si pro své účely úplně přepsal, a vůbec nechápu, jak v takové formě co se distribuuje vůbec někomu může fungovat.

[anicka]

treba na Perlovych a jinych modulech

To nekdy fungovalo? Ve fedori bugzille na to byvala spousta bugu, my to v suse radeji mame vypnute rovnou a pokud vim, lidi ze cpanu na to nadavaji, kudy chodi. (Shodou okolnosti spravuju vetsinu baliku s perlovymi moduly v nasi distribuci, takze zrovna tady mam celkem prehled.)

A vubec... jedna ze zivota:

Mejme balicek A a pri updatu ho nahradime balickem B. Co se bude dit, co se bude poustet?
pretrans baliku A
--updaty dalsich baliku
pre baliku A
instalace souboru z baliku B
post baliku B
preun baliku A
odstraneni souboru z baliku A, ktere nejsou v baliku B
postun baliku A
--updaty dalsich baliku
posttrans baliku B
Docela k zblazneni, ze? A pro srovnani, takhle to dela Debian:
http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

No a tak bych mohla vzdychat do aleluja...

(Toho, ze rikam-li APT, myslim tim APT+debiani balicky, se prosim nelekejte, odjakziva jsem zvykla vnimat ty dve veci spolecne, ne jednu bez druhe. A porad jsem presvedcena, ze APT s debianimi balicky se chova rozumneji nez cokoliv, co znam, s rpmkovymi balicky.)