APT je ale vůl (downgrade LibreOffice s APTem) (diskuse)

[Marián Kyral]

Ono se o Gentoo tvrdí, že je složité:

emerge -1 =app-office/libreoffice-3.6.2.2

Akorát ta kompilace chvilku trvá

Jinak s 3.6.3 na Gentoo žádný problém nemám. Žádného zpomalení jsem si nevšiml.

[Bedňa]

V Debiane/Ubuntu je to tiež jednoduché

[Marián Kyral]

NO já si říkal, že to přece není možné, aby to nešlo.

[kotyz]

Nejsou na to nějaký generic/precompiled balíčky? Kdo to má kompilovat celý odpoledne a půlku večera?

[Marián Kyral]

Ano. jsou. Je to libreoffice-bin, ale zatím jen verze 3.5.5.3.

Kompilace není až tak problém. Záleží na výkonu počítače. Ten můj to většinou stihne pod pět hodin. Více mě poslední dobou štve webkit-gtk. Ten se kompiluje skoro hodinu a půl.

[hanoj]

Synaptic umi vynutit verzi nejakeho baliku.

[Aleš Kapica]

Jak jsem pochopil, nepoužíváš oficiální repozitář, ale svůj vlastní. Chyba není v APTu, ale v tom, že pořádně nechápeš co a jak vlastně dělá.

A pokud jde o LibreOffice, tak verze z oficiálního debianího unstable funguje svižně.

[pushkin]

No, ona je to otázka. To, co nechápu je, proč se APT snaží používat balíčky, o kterých již musí vědět, že nejsou dostupné (k čemu by jinak bylo apt-get update?). To, že cesta k cíli může být i jiná je mi jasné, tak to prostě chodí

Jinak vlastní repozitář používám z důvodů aktuálnosti software ... sám jistě dobře víš jaké má Debian dopravní zpoždění

[Aleš Kapica]

Apt se snaží nainstalovat vždy tu nejaktálnější verzi - bez ohledu na to, jestli je skutečně dostupná. Informace o ní má uložené. Příkaz apt-get update jenom stáhne informace o nových balících. Ty staré se souboru /var/lib/dpkg/available neodstraní. Pokud chceš provést downgrade, tak to musíš při instalaci říct.

O tom která verze je aktuální rozhoduje číslo verze balíku. Já kupř. u balíků které si rekompiluji sám navyšuji číslo subverze, aby mi to při aktualizaci nepřebil. Kupř. distribuční balík s verzí 1.6.0-1 zkompiluji jako 1.6.0-2. Kdybych mu číslo subverze ponechal stejné, tak ho apt přeplácne distribučním balíkem, který má větší prioritu. Na druhou stranu je-li distribuční verze navýšena, tak to má svůj důvod a tím pádem je pro mne žádoucí aby mnou kompilovaný balík přeplácnul.

Pokud jde o zpoždění, tak ono je to dost relativní. Balíkům, které jsem si dřív aktualizoval sám, protože je nikdo moc nepoužíval, se poslední dobou docela věnuje pozornost. Takže je neřeším. Typicky právě libreoffice je balík u kterého se to nevyplatí. Pro mé použití změny nejsou tak zásadní abych tím ztrácel čas.

[pushkin]

Příkaz apt-get update jenom stáhne informace o nových balících. Ty staré se souboru /var/lib/dpkg/available neodstraní.

Aha, to je ono - otázka teď je, proč APT neodstraní informace o balících, které nejsou dostupné? Je to bug nebo fíčura, která může mít své využití? Za sebe bych právě považoval logické již nedostupnou verzi ze seznamu odebrat (tak, jak to řeší zypper).

[Aleš Kapica]

Z jednoduchého důvodu. Debianí balíčkovací systém je navržen tak, že umožňuje zachovat x verzí balíku v rámci jedné repozitory. Dříve tomu tak i bylo, jenže při dnešním objemu dat v oficiální repozitory by to zbytečně komplikovalo replikaci. Takže tam najdeš jen balíky, které jsou nejčerstvější pro jednotlivé variace. Pokud si ale udržuješ repozitář sám, tak ti nic nebrání si tam ty balíky zachovat a pak se k nim podle potřeby moct vrátit.

[aaa]

Z jednoduchého důvodu. Debianí balíčkovací systém je navržen tak, že umožňuje zachovat x verzí balíku v rámci jedné repozitory.

WTF? Jak to souvisí s tím, že APT "instaluje" balík, který není dostupný - tedy není v seznamu?

[pushkin]

Přesně tak. Při vytváření repozitáře se vytváří Packages.gz, ve kterém je seznam balíků v daném repozitáři. Když se APT neřídí tímto souborem, k čemu tam pak je?

[Matlák]

O tom která verze je aktuální rozhoduje číslo verze balíku. Já kupř. u balíků které si rekompiluji sám navyšuji číslo subverze, aby mi to při aktualizaci nepřebil.

mno, to mi nepřipadá moc uživatelsky přívětivé.

[Marián Kyral]

Na Gentoo má uživatelský overlay větší prioritu než systémový.

[Aleš Kapica]

Kdybyste se obtěžovali pročíst tuhle diskuzi pořádně, tak byste se prolinkovali na stránku, kde se hovoří o tom jak to řešit přes priority.

Já to řeším tak jak mi to vyhovuje a nikomu to nevnucuji. APT je dobrý nástroj, jako nedostatečný se jeví především pokročilým uživatelům, kterým nestačí základní funkcionality, ale zároveň jsou příliš líní aby se s ním lépe obeznámili.

Padla tady také zmínka o aptitude. Je to už několik let co není pravda, že by to byl nástroj lepší než apt-get. Každý ale ať si používá co chce. A právě o tom je GNU/Linux.

[Marián Kyral]

Tak nevím. Matlák jen zkonstatoval, že zvolený postup není právě nejpříjemnější. Já jen doplnil, že na Gentoo jsou priority. No a původní pisatel by si mohl říct: "Aha, třeba i v APT jsou priority". No a to je celé. Přece mu to nebudeme rovnou servírovat

[pavlix]

Padla tady také zmínka o aptitude. Je to už několik let co není pravda, že by to byl nástroj lepší než apt-get. Každý ale ať si používá co chce. A právě o tom je GNU/Linux.

Nemyslím si, že by opensource, Linux, a už vůbec GNU, byly o úmyslně zbytečné duplikaci nástrojů.

[pavlix]

Chyba není v APTu, ale v tom, že pořádně nechápeš co a jak vlastně dělá.

Jeho popis mi přijde dostatečně jasný, abych se takovéhoto komentáře vyvaroval. Sice dělá jednoduchou věc složitě, zato APT reaguje zcela špatně a nesmyslně.

[stps]

Slovo vul v titulku urcite neni urazka ani vulgarismus. Vzdyt sam apt-get o sobe tvrdi toto: "This APT has Super Cow Powers."

A umi i bucet:

apt-get moo
         (__)
         (oo)
   /------\/
  / |    ||
 *  /\---/\
    ~~   ~~
...."Have you mooed today?"...

[pushkin]

Není, a ani to tak nebylo myšleno Jde prostě o povzdechnutí

[AsciiWolf]

Takže "vůl" v článku znamená "vykastrovaný APT"?

[Aleš Kapica]

Ano. Ten se ovšem jmenuje apt4rpm .

[Josef Kufner]

No vidiš to. A kdybys nebyl vůl, tak bys použil Aptitude, zvolil si v nabídce, kterou verzi chceš a po instalaci zablokoval tu novější. A nebo bys tam pomocí dpkg rovnou nasypal konkrétní balíčky a nechal Aptitude jen opravit závislosti.

[Smörgås]

Rád by som si prečítal, ako na Debiane postaviť slušný desktop. Normálne nejaké varianty na GNOME, KDE, light desktop prostredie, kanceláriu, multimédiá, odporúčané repozitáre, atď.

[kyytaM]

Pouzivat testing/unstable a standardne repozitare s contrib a non-free. Externe repo staci Debian-multimedia.

[Václav HFechs Švirga]

Souhlasím s Smörgås, používam testing (doporučuju instalovat z neinstall obrazu), repozitář debian multimedia + KDE na notebooku a žádný problém (ani s drivery), subjektivně mi to přišlo méně problematické než různé ubuntu a podobně desktop friendly zaměřená distra (tedy žádné probděné noci s laděním konfiguráků se nekonaly, skoro vše fungovalo hned včetně webkamery).

[depka]

imho ubuntu je na notebooku neprekonane (bohuzel)

[Aleš Kapica]

Při vší úctě - překonaný názor.

[gtz]

a to proč? co je na něm tak vyjímečeného, že to ostatní nemají?

[Aleš Kapica]

že by ten ujetý přístup k tomu jak má vypadat pracovní prostředí?

[gtz]

Určitě

[depka]

uz jsem to tu parkrat zminoval, je to predevsim rychlost odezvy - pokud je to dnes jiz prekonany nazor, doporuc mi distribuci ktera je stejne svizna - budu jedine rad (na ubuntu se mi jinak vubec nic nelibi)

a ujetym pristupem k tomu jak ma vypada prostredi to neni - pouzivam klasicky panel

[gtz]

Jak jsem zde párkrát zmiňoval OpenSuse má myslím hodně slušnou odezvu. Používám ho i na starších počítačích a rychlostně dostačuje. Jistě na starším železe používám Trinity popř. Xfce a zhruba před půl rokem když jsem se pro jednoho známého zamýšlel co dát na desku s Atomem tak nakonec volba padla stejně na OSS 12.1. Kdybych si musel něco vybrat z Buntu klonů tak bych asi zvolil LM, který je myslím lepší než samotné Buntu.

[depka]

jeste jsem zapomel zminit ze bych preferoval "deb based" distribuce, takze asi zkusim linuxmint debian

[Bedňa]

LMDE je OK, ale u mňa nakoniec zas zvíťazil Debian testing, ale s minťáckym Mate.

[gtz]

Měl jsi zůstat u Suse. Zlatý zypper

[pushkin]

Však já ho používám dodnes Jen mám doma openSUSE a v práci Debian (kvůli některým specifickým balíkům). Takže mám srovnání z první ruky

[gtz]

Tak to má být, tak je to správné

[aaa]

protože APT nepokládá "downgrade" jako relevantní možnost při řešení závislostí

V podstatě je to mizerný správce balíků, ale Debianistům ani slovo....

[pavlix]

A pod tím je i oproti obyčejnému ošklivému RPM dost mizerný balíčkovací systém. Stačí se podívat na jednoduchý specfile versus hromadu souborů, které řídí build debianího balíku.

[Martin Mareš]

Jednoduchý specfile je lákavý. Ale ledva potkáš nějaký trochu složitější specfile plný maker, chuť k jídlu Tě přejde ;) Hlavně jsem moc rád, že Debian nepoužívá obludy typu SRPM a balí zdrojáky úplně přímočaře.

[pavlix]

Jednoduchý specfile je lákavý. Ale ledva potkáš nějaký trochu složitější specfile plný maker, chuť k jídlu Tě přejde ;)

Neříkám, že je to kdovíjaký ideál, ale zvykl jsem si :).

Hlavně jsem moc rád, že Debian nepoužívá obludy typu SRPM a balí zdrojáky úplně přímočaře.

Po odříznutí hlavičky je SRPM archiv, který obsahuje pouze archiv zdrojáků, patche a specfile. Nevím co bys chtěl více přímočarého, Debian mi zdaleka tak přímočarý nepřijde, to spíš třeba Gentoo.

[Martin Mareš]

Po odříznutí hlavičky je SRPM archiv,

No právě: proč má sakryš nějakou proprietární hlavičku, místo aby to byl normální archiv?

[aaaa]

Ta hlavička je asi tak stejně "proprietární" jako má Debian "proprietární" balíky DEB.

[Martin Mareš]

Debianí balík lze rozbalit standardními Unixovými nástroji (ar, gzip, tar), RPM nikoliv. U binárního balíčku určeného k instalaci to tolik nevadí, u balíčku se zdrojáky, který je často potřeba rozbalovat i na jiných distribucích či dokonce jiných OS, to příjemné není.

[gtz]

RPM? na co máme mc? klepneš, rozbalíš co a jak kam chceš,

[pavlix]

U binárního balíčku určeného k instalaci to tolik nevadí, u balíčku se zdrojáky, který je často potřeba rozbalovat i na jiných distribucích či dokonce jiných OS, to příjemné není.

Já bych to osobně viděl stejně u zdrojových i binárních balíků. I ty binární může mít smysl auditovat za pomoci standardních nástrojů. Ono i to RPM se dá při troše snahy zpracovat standardními nástroji, i když už ne tak přímočaře. Já osobně bych neměl problém s přesunem metadat dovnitř archivu.

[Tutor]

Debianí balík lze rozbalit standardními Unixovými nástroji (ar, gzip, tar).

To ještě neznamená, že je to automaticky po všech stránkách to nejlepší řešení. RPM je také jen variace na "standardní unixový nástroj" cpio, především je to otevřené, dobře dokumentované a snadno přenositelné řešení. Když si Debianí balík přenesu na Windows, tak ho tam standardními Windows nástroji neotevřu, to ještě neznamená, že je proprietární.

[pavlix]

No právě: proč má sakryš nějakou proprietární hlavičku, místo aby to byl normální archiv?

Mám na to stejný názor. Nicméně, v čem se názorově lišíme je, zda má toto kritérium větší váhu než redundantní bordel v archivu samotném, ve kterém se musí člověk při tvorbě deb balíčku vyznávat, oproti ebuildům, specfilům a podobným řešením založeným na formě „receptu“.

P.S.: Považuj označení „redundantní bordel“ za stejně subjektivní výraz odporu jako tvé „proprietární“ a „obluda“.

[Aleš Kapica]

Měl jsem za to, že se ve věci víc vyznáš, než tady předvádíš. Protože jinak bys věděl, že to je v zásadě stejné, jen s tím rozdílem, že u debianích zdrojových balíků se nepracuje s jendním óbr skriptem, ale je rozdělen na do více samostatných souborů, které hrají svou vlastní specifickou roli. Tím vlastním "receptem" pro sestavení balíku je soubor rules, závislosti řeší control a verze changelog. Zbytek už záleží na tom jak se má provést vlastní sestavení binárních balíků.

[pavlix]

Protože jinak bys věděl, že to je v zásadě stejné, jen s tím rozdílem, že u debianích zdrojových balíků se nepracuje s jendním óbr skriptem, ale je rozdělen na do více samostatných souborů, které hrají svou vlastní specifickou roli.

To je hezká teorie. Nicméně při pohledu do skutečných deb balíků bylo vidět, kolik je tam řádků kódu, které v ebuildech vůbec nejsou potřeba. Přitom toho ve výsledku ebuildy umějí víc.

[Jakub Lucký]

Talk is cheap, show us the code!

Prostě chci vidět konkrétně a na příkladech, o čem se tady mluví...

[pavlix]

Připomeň se během týdne…

[Aleš Kapica]

To že je některý maintainer prase ještě neznamená, že je špatný systém a jeho nástroje. Trochu jsem do toho před lety nakouknul - když jsem lokalizoval Synaptic. Tehdy nějaké Ubuntu ještě neexistovalo a já ho používal v rámci Mandrake nad apt4rpm. Abych pochopil význam a smysl některých hlášek, tak jsem se musel podrobně seznámit jak s deb tak rpm.

Kdo hodnotí APT na základě zkušenosti s Ubuntu, neví o čem mluví, protože i když také používá deb balíky, teprve po přechodu na roll-on distribuci zjistíte v je APT a jeho nástroje lepší.

Jedna z velkých předností Debianu je, že pokud nejsem spokojen s kvalitou distribučních balíků, tak mi nic nebrání dělat si balíky vlastní, vyhovující mým představám a zároveň je i veřejně nabídnout.

[pavlix]

To že je některý maintainer prase ještě neznamená, že je špatný systém a jeho nástroje.

Tak to klidně může být. Ale já jsem osobně zatím nikdy nutně nepotřeboval udělat deb balíček. A když jsem to chtěl zkusit, vyplynulo z toho, že musím nechat vygenerovat tu strukturu a do ní porůznu doplňovat věci. Po stejné nebo delší době, jakou mi bez předchozích znalostí trvalo vyrobit první RPM balíček, jsem se rozhodl s DEBem přestat ztrácet čas.

Kdo hodnotí APT na základě zkušenosti s Ubuntu…

Nemám nejmenší tušení, co to má společného s Ubuntu.

Jedna z velkých předností Debianu je, že pokud nejsem spokojen s kvalitou distribučních balíků, tak mi nic nebrání dělat si balíky vlastní, vyhovující mým představám a zároveň je i veřejně nabídnout.

Pokud se to v rámci linuxového světa považuje za přednost Debianu, pak nejspíš budeš mít v zásobě mainstreamové distribuce, které toto narozdíl od Debianu neumožňují.

P.S.: Jak už jsem psal výše, nechuť k balíčkování ve stylu Debianu je subjektivní srovnání toho, co jsem viděl v návodu i v konkrétních balíčcích s tím, jak jednoduše se mi dařilo naložit s balíčky pro Gentoo a Fedoru.

[Aleš Kapica]

Ubuntu sice vzalo hodně z Debianu, bohužel zůsob tvorby release převzalo od RPM distribucí. Čímž z mého pohledu dost hodně pošramotilo pověst APTu.

Už jsem několikrát zmiňoval - každý ať si používá co mu vyhovuje. Mě nebaví neustále něco někde kompilovat. Spravuji několik strojů, a tak je pro mě jednodušší držet se v maximální míře distribučních verzí. Vlastní verzi dělám pouze pro ty balíky, kde to má svůj smysl. V poslední době se ale aktivita maintainerů balíků, které jsou pro mne důležité o dost zlepšila, takže kromě balíků s jádrem jsem dělal pouze vlastní verzi pro VDE2 a xNBD. A to jen proto, že jsem si k nim potřeboval přidat vlastní věci.

Tahle debata vznikla kolem balíků LibreOffice - používám distribuční. Žádné problémy s nimi nemám. Osobně mi přijde efektivnější a rychlejší upozornit na případný problém či chyby maintainery balíků, než dělat a udržovat vlastní repozitory.

Problém je, když maintaineři tyhle věci dál nepouští a problém řeší vlastním patchem. Je-li to tedy možné a žádoucí, snažím se komunikovat přímo s autorem aplikace.

[pavlix]

Tahne diskuze vznikla tím, že si někdo rýpnul do APTu a já jsem si pod tím rýpnul i do DEBu. Není to nic závažného a není to ani nic o Ubuntu.

[Tutor]

Ubuntu sice vzalo hodně z Debianu, bohužel zůsob tvorby release převzalo od RPM distribucí. Čímž z mého pohledu dost hodně pošramotilo pověst APTu.

Jinými slovy APT je skvělý nástroj jen, pokud má dokonale předžvýkané repozitáře ve stylu Debianu?

A není to spíš doklad toho, že je tento nástroj slabý, když si s větším chaosem neporadí?

[Aleš Kapica]

Srovnávat organizovaný bordel s chaosem je přinejmenším scestné.

[Tutor]

Na základní myšlence to nic nemění. říkejte tomu jak chcete, ale sníží-li se objektivně "kvalita organizace" repozitáře, právě tehdy se projeví kvality správce balíků nejvíce.

[David Jaša]

a balí zdrojáky úplně přímočaře

Už umí balit patche po jednom, nebo se z nich furt generuje ta obluda?

[smazáno]

roky