Názory k článku
Je lepší aptitude místo apt-get nebo je to jedno?

No ono při tom hledání (pokud chcete podobný výstup, jako u aptitude) stačí apt-cache říct, aby hledal ten řetězec pouze v názvech balíčků a ne všude (parametrem –names-only. Ne vždy je vhodné hledat pouze v názvech balíčků, leckdy se klíčové slovo vyskytuje pouze v popisu) a pokud nutně potřebujete seřadit výsledek podle abecedy, tak tu přece máme pípu a za ní číhající sort, proboha…
To (defaultní vyhledávání apt-cache versus aptitude) autor jaksi (zřejmě omylem) zapomenul při té „efektní“ demonstraci s gimpem zmínit.

mam k tomu jednu poznamku:

apt potrebuje podstatne mene sys. prostredku – pravdepodobne prave proto ze ma na vsechno solo binarku a nesnazi se chytracit.
Na starickych systemech je proto casto jedina nadstavba ktera lze tak nejak pouzit. napr: via 500MHz, ci P2 266 s 28MB ram apod.

v „normalnich“ systemech nemate sanci rozdil postrehnout ale na historickych slupkach je to uz podstatne.

Také jsem přešel rovnou na ncurses rozhraní, o textovém jsem se dozvěděl až pak.

Před nějakou dobou jsem z Debianu Etch přecházel na Gentoo (nadchly mě hlavně USE flags) a byl jsem překvapen, jak moc se dají osekat závislosti balíků. Starý dobrý apt-get prostě instaloval ve stylu yum vše možné a zbytečné, hlavně aby to fungovalo.
Pak jsem přešel zpět na Lenny (tehdy testing) a rovnou na aptitude. Mé obzory v package managementu dostaly nový rozměr – na pohodlí ncurses si šlo zvyknout snadno. Pokud balíček neměl tvrdé závislosti, ale jen „recommended“, šel snadno odoznačit (nepamatuji si apt-get, který by neinstaloval recommended/sug­gested), v případě nespokojenosti výsledku (do náhledu přes „g“ jsem se zamiloval) jsem akci prostě mohl doupravit nebo stornovat, daleko rychleji, než bych to dělal u „textového“ nástroje změnou argumentů/kon­figuračního souboru. Později přišla velká úleva od neustálého kontrolování závislostí (ano, mám rád čistý a minimální systém) v podobě možnosti „Neinstaluj recommended balíky“ – zároveň je však v náhledu rozbalovací menu s těmito balíky, takže je možno nahlédnout, …

Popravdě jsem myslel, že aptitude (jelikož používá svůj algoritmus na kalkulaci závislostí) je nástavba maximálně tak nad APT databází, ne nad nástrojem apt. Nevím, kde leží pravda.
Nicméně vím, že k apt-get / apt-cache se (doufám) nebudu muset vracet. :)

PS: Hledání v ncurses aptitude není tak šťastné. Pokud začnu zadávat „vim“, vyskočí na mě nějaké pluginy, musí se na to chytře se regexpy („^vim$“) a najde to (bez nutného mačnání ‚n‘ pro ‚next‘) konečně „vim“ virtuální balík.

Příspěvek pro mě hodnotnější než článek. Nevěděl jsem, že se dají zadávat regexpy ;). Ani nevím, proč jsem to nezkusil.

Jde ještě víc – např. „~i~Dgimp“ (instalované balíky, co závisí na balících, majících v názvu „gimp“). Vizte manuál.

Nejčastěji používám ~b, vyhledá broken balíčky, když se řeší divoké závislosti. Moc sympatické.

Na to v ncurses stačí zmáčknout „b“, není potřeba zadávat hledání

Nechce sa vam riesit dilema archlinux vs debian?
Doporucujem OSX alebo Windows.

To je jak vyber mezi krasnou konkubinou a strelou mezi oci..

Nechce se Vam resit dilema apt vs. aptitude, zkuste Gentoo :-) http://www.gentoo.org/

Mno zkousel jsem sabayon, ten nativní sabayon bal. systém byl nejakej divnej, kvůli jednomu balicku, ktey nesel aktualizovat, to šlo celé doháje.

Portage to nevyřešilo, tam ten baliček byl ve stare verzi.

Navíc mi portage odmítalo nainstalovat netbeans…

A portage bylo také oproti ABS/AUR neskutečně pomalé…

Pacman vice user-friendly ?? :)

aptitude install balicek
pacman -Ssyu balicek (nebo tak nejak, fakt uz si tu zrudnost nepamatuju)

a jak nejaky balicek vyhledat to uz si nemuzu vzpomenout vubec. Zato instal, show, search atd.. jde asi jen stezi zapomenout ;)

> pacman -Ssyu balicek (nebo tak nejak, fakt uz si tu zrudnost nepamatuju)

je to pacman -S balicek :)

Fakt sorry, ale install je pořád mnohem srozumitelnější :-)

Archlinux neznam, a muj prispevek je tak ciste teoreticky, nicmene obecne mam za to, ze rozdelit funkcnost do vice nezavislych casti je temer vzdy lepsi. Hlavne proto, ze sem se naprosto ztotoznil s „unixovou“ filozofii – kazdy nastroj dela jednu jedinou vec, dela ji dobre a snadno spolupracuje s ostatnimi nastroji.

To se samozrejme tyka pouze rozdeleni [ dpkg ] – [ apt/aptitude/dse­lect ].

Co se vsech dselect/aptitu­de/apt tyce – tam to vidim jako nezavisle programky, ktere delaji tu samou vec, ale kazdy trosku jinak. Coz znamena, ze clovek muze vybrat co mu vic vyhovuje – opet podle nejlepsich tradic unixove filozofie.

Ja zadne „dilema apt-get vs. aptitude“ nevidim. Stejne tak jako nevidim dilema vim vs. emacs, nebo firefox vs. opera vs. chrome.

Aptitude pouzivam roky k plne spokojenosti. Pri cteni clanku jsem se dozvedel pro mne vsak novou vec – aptitude obsahuje TUI. Doposud jsem znal jen CLI :)

U běžného počítadla to ani tak nevypada ale nedávno jsem instaloval něco na nějakém starším stroji a zdá se mi že aptitude je proti aptu o něco pomalejší.

Ano, aptitude je pomalejší právě kvůli tomu, že má složitější algoritmy pro řešení závislostí

nebude port zypperu na apt/deb? Vyzera to fayn.

určitě nebude. Zypper hodně využívá výhod RPM a repo-md, což mimochodem znamená velmi snadnou přenositelnost do Fedory (už jsem zkoušel). Lze myslím vyloučit, že by kdokoli mimo DEB distra investoval prostředky do portace zypperu na DEB.

Navíc, kdyby Debianisti chtěli, dávno by Apt/aptitude vyrobili nějakou inteligentní syntaxi a efektivní informační výstup. Ale oni nechtějí, protože jsou přesvědčeni, že současný stav je skvělý.

samostatnou kapitolou je solver. Ten je nezávislý na balíčkovacím systému, a zřejmě by šlo jej forknout, ale opět, pokud Debian nechce RPM a repo-md, musí si to udělat sám. Tojemyslím jasné. V suse to za ně nikdo dělat nebude.

PS.: Nědělám si iluze, že by v Debianu vůbec měli o něco takového zájem.

normalne vazne sa pytam, co je na aptitude zle…pouzivam to uz x rokov a stale som nedosiel nato, v com je to akoze nepouzitelne (ked som o tej udajnej nepouzitlenosti tolko cital). :)

Na Aptitude neni vyslovene spatne nic. Je to standardní nástroj, se standardními schopnostmi. Nic hrozného, ale také nic excelentního.

O co teda přicházíme, my co používáme apt-get/aptitude? V čem je Zypper lepší?

Nedá se říct „přicházíme“ .. APT* je určitě 100× lepší než YUM*.
- konzole:
Po používání zypper, který je pěkně svižný a easy na používání, trpím nasraností, že nějaký debil v debilanu vymyslel apt-cache, apt-get, apt-neco-jineho .. udělal jsem si na to tabulku .. je úděsná. Pracuji se Solaris, CentOS, Debian, oSuse .. v komandlajně je na tom Debian stejně tragicky jako historicky konzervativní Solaris – jenže ten to tak má už přes 20 roků, kdy se UserFriendly neřešilo).
Když mi někdo řekne argumentaci, ze search je jasně přes apt-cache, protože to je práce pouze s metadaty .. ptám se tedy: proč se metadata refreshují příkazem „apt-get update“ a ne „apt-cache update“ ?!?! .. „update“ dělá refresh metadat, „upgrade“ dělá update baličků .. lol
Nejde napsat „apt-get update jeden-balicek“ (ignoruje jméno balíčku a updatuje vše) ! když chci updatnout jeden balíček, musím napsat „apt-get install jeden-balíček“ ! wtf ? to vymýšlela ženská, že to zcela postrádá logiku ? :-D
A nainstalovat balíček ze souboru ? apt-get mi to nesežral .. musel jsem použít „dpkg install balicek.deb“ .. ale ten neumí řešit závislosti přes repos :-(
Kdežto zypper mi udělá vše co potřebuji z repos nebo souboru či kombinovaně, včetně závislostí s logickými parametry volání .. Yum také, ale otřesně pomalu..
- nadstavby:
nad Zypperem je Yast jak v GUI tak ncurses podobě. Jsou si velice podobné. Po zaškrtnutí každého jednoho balíčku IHNED navrhnou řešení případných závislostí (což yumex neumí). Aptitude v ncurses je hůř ovladatelné než yast modul pro balíčky. GUI nadstavbu APTu jsem neviděl.

Rozhodně se mi líbí (myslím že to je od oSuSE 11.2), že v nadstavbě po přepnutí pohledu do zvoleného repo můžu tento vynutit jako ten správný pro běžný update, takže novější balíček z jiného repos mi to nepřeflákne. Vhodné třeba při přidání neoficiálního repo s nějakou aplikací, tu si přidám, odtamtud mi ji to updatuje, ale ostatní balíčky bere z oficiálních repos a ignoruje případné vyšší verze v tom neofiko repo. Takže se mi to nerozhasí. Toto nastavení překročí pouze dist-upgrade, které updatuje na nejvyšší verzi bez ohledu na repos.
Takže se můžu zeptat reklamním sloganem: umí tohle váš kečup .. eee .. manažer balíčků ? :-D
PS: mluvím o Zypper z oSuSE 11.x .. je zcela přepracovaný a zcela jinak rychlý než předešlá verze, která si klepala na rameno s Yumem :-)

K tomu je třeba dodat několik zásadních věcí:

1) Zypper má objektivně nejvýkonější solver pro řešení závislostí, postavený na SAT. Solver Aptu je nejhorší vůbec (viz demonstrace na tránkáích tvůrců SMARTu), a ani solver Aptitude se zypperu neblíží ani vzdáleně.

2) Zypper má skvěle navrženou syntaxi. Každý příkaz lze zapisovat zkráceně, například místo „zypper install“ můžeme napsat „zypper in“

3) Zypper umí pracovat s repozitáři přímo v CLI. Lze je efektivně povolovat, zakazovat, přidávat či odebírat, nastavovat jim priority či autorefresh.

4) informační výstup Zypperu je vynikající. Vše řadí do přehledných tabulek.

5) Zypper rolišuje mezi patch a update (tedy mezi instalací oprav, a instalací nových verzí balíků)

6) Zypper umí instalovat patterny. (tematické skupiny balíků). Debian to ochcává metabalíčky.

7) Zypper je rychlejší než Apt, o Aptitude ani nemluvím.

8) Zypper se neustále rozvíjí. Funkcionalita Aptu i Aptitude více méně stagnuje.

Názorná ukázka používání zypperu:
http://en.opensuse.org/Zypper/Usage

Já jsem je nechtěl až tak deptat :-D

Jo a samozřejmě je dobré zmínit, ze když má oSuSE jako desktop běžný BFU, tak GUI Online-Update či Správce programů updatují jen kritické a bezpečnostní chyby. Takže sice nemají všechny balíčky super-last-up-to-date, ale nic si nerozeserou.
Kompletní update na last verzi všech balíčků je třeba udělat vědomě volbou „Balíček → Všechny balíčky → Aktualizovat pokud existuje novější verze“.
Chvilku mi trvalo, než jsem tohle zjistil, ale došlo mi, že to je tak správně, pokud se defaultně počítá s tím, že u GUI bude mezi klávesnicí a židlí sedět BFU. Jsem líný si zjistit, jestli si pro sebe můžu nastavit jiné chování. Zatím mně to jedno kliknutí navíc nezabilo.
A to už jsme u polemiky, které distro je víc user friendly. *buntu to vykřikuje, oSuse to dělá. :-P

asdfghjkl: ale ubunťáci taky přidávají repos v komandlajně. Podle všech článků co se píšou o přidání jakékoli aplikace to asi ani jinak nejde! Všude je „pastněte do komandlajny tohle, co vám přidá repozitář“ .. LOL .. user friendly ! .. LOL
Když jsem viděl jaké hrůzy provádí můj šéf na Ubuntu, když si chtěl přinstalovat XBMC .. nikdy .. takové distro je třeba hodit do koše. Jestli chce Ubuntu být UserFriendly na desktopu, tak musí změnit hodně věcí.
Tu uživatel openSuse si komunitní repos přidá v GUI na pár kliknutí a ostatní malé nekomunitní se mu přidají samy po vybrání zvolené aplikace přes OneClick. To jsou ale věci, kterým ubunťák neuvěří dokud to nevidí na vlastní oči, protože on má přeci nejlepší distro. :-)
Humorné je, že znám pár ubunťáků, co po nějaké době zvyknutí si na jednoduchost těch věcí v oSuse po návratu k *buntu prskají jako křečci. Jo, na lepší se zvyká rychle. Já bych se už taky nevrátil k windows. Jejich způsob instalace aplikací bych už asi psychicky nepřežil :-D

PS: nejsem fanatický příznivce žádného distra, pracuji s 5 různými distry linuxu a Solarisem. Na svém desktopu používám to distro, které je pro mne nejvíc user friendly, administrace je jednoduchá a svižná. Prostě takové, kde se můžu věnovat práci nad tím a ne furt řešit sytémové divnosti. V současné době mi tak vyšlo oSuse.

Hehe, v Ubuntu sa repos tiez zadavaju (aj edituju) v GUI, trepes blbosti. V navodoch je to cez command line koli jednoduchosti. Je to rcyhlejsie ako vysvetlovat spustte si package manager , v menu vyberte, bla bla…

Vtip je v tom, že je mnohem jednodušší zadat příkaz zypper ad repo s parametry: „zypper ar –parametry URL alias“ než otvírat apt sources list pomocí nano, nebo s využitím cat přilepit na konec souboru daší řádek. Nemluvě o tom, že formát apt sources list souboru nepopropuje žádné nastavení repozitáře, a to se pak musí udělat v jiných konfigurákách.

Ja tiez stale nechapem preco sa to neriesi cez echo.....
Staci pridat jediny riadok na koniec a problem solved ===:> echo rulez
Teda samo este nasleduje apt-get update, ale urcite jednoduchsie ako robit to cez vi, nano, gedit ci cokolvek take…
Mna najviac stve, ze ked to niekto spravi moc BFU odolne, tak je problem, ze BFU sa nikdy nedozvie co vlastne zmenil v configu a preco mu zrazu ,,wannabie zazracne stabilny linux" padne.
Toto vravim z vlastnej skusenosti, moje prve pokusy s Xkom dopadly hrozne a kedze som si nevedel v konzole pustit links / lynx + google, nepomohlo nic len preinstalovat.
Teraz by to bolo riesenie jedneho prikazu na rekonfiguraciu Xka :)
Ale noobovi nevysvetlis, specialne noobovi s root pravami :D:D:D:D

V tom případě by vůbec neměl používat Debian. DPKG totiž klade dost imbecilní otázky, na které musí uživatel odpovídat.

Druhou možností je dpkg-reconfigure debconf, nastavit debian frontend na noninteractive, priority na critical, a čekat, až se vinou některých nezkonfigurovaných balíků rozesere systém. Tomu říkám balíčkovací systém pro průměrného uživatele.

Ještě jsi zapomněl na alias aptitude=„aptitude -y“, ať si to na vše automaticky odpoví ano :)

… to není dobré. Já jsem se na psychiatrii dostal a psycholožka mi tam diagnostikovala poruchu osobnosti.

Byl jsem dlouhou dobu uzivatelem debianu a muzu rict ze me vzdy trapil rozdil mezi apt a aptitude. Stalo se mi ze aptitude instalovalo vic zbytecnych zavislosti nez apt. Mozna je situaci jiz trochu jina ale od te doby co pouzivam archlinux se muj problem vyresil.

celkom ma prekvapil clanok, zil som v tom, ze kazdy predsa MUSI pouzivat aptitude

uz je mi jasne preco tolki ludia opovrhuju debianom, ked pouzivaju apt-get miesto ncurses aptitude, bez neho by bolo akekolvek zlozitejsie riesenie zavislosti hroza…

Mě zrovna textové rozhraní aptitude přijde stravitelnější, než to ncurses. To se podle mě dost nepovedlo.

nevidim ako by mohlo byt prijemnejsie (alebo vobec mozne) v CLI vyhladavat baliky, menit ich stav (hold, automatically installed, purge, …), riesit konflikty a prezerat si najdene riesenia, menit vysledny zelany stav… vsetko interaktivne s funkcnym regexp searchom a moznostou nechat si zobrazit changelog

Já nemluvím o tom, co to umí, ale o tom, jak je to uspořádané, jak to vypadá. To GUI je prostě chaotické, a nepřehledné. nCurses nástavby nad zypperem nebo urpmi jsou mnohem přehlednější

asi to bude individualne, nemal som s aptitude nikdy problem…

určitě to bude individuální. Ale já jsem dodneška nebyl schopen zcela pochopit, jak to vlastně funguje, a to ani s manuálem. A v tom případě asi něco na ergonomii špatně bude.

Presne tak, nad Zypperem je nadstavba Yast bud v GUI nebo take v ncurses, coz je podobne jako aptitude. Musim rict, ze jsem o tom nevedel zhola nic, prechazejic z Fedory s otresne pomalym YUMem, a necinilo mi zadne problemy tu ncurses nadstavbu pouzivat. Kdezto s aptitude je neustaly zapas kde kam cim skocit a co si to proboha zase vymyslel. Nemluve o podivnem deleni balicku v debianu.

Nápodobně jsem s ním neměl nikdy problém (co se ovládání týče) – pokud zapomenu nějakou zkratku, stačí „?“. Neříkám, že aptitude je bůhví jak super uspořádané, ale u takového VImu se o intuitivnosti také nedá hovořit. :)

Musím bohužel souhlasit, já se v tom ncurses taky moc nevyznám. Hlavně si člověk musí pamatovat hromadu kláves k ovládání a taky znaků, které označují, v jakém stavu balíček je. Jsem zvyklý i na Ubuntu (když ho někomu spravuju) používat aptitude na řádce.

aptitude ma aj menu, ktore dokonca funguje aj s mysou…

Jedine klavesove skratky ktore si treba pamatat su:

[+] instalovat
[-] odinstalovat
[g] commit, tj vykonaj zvolene zmeny
[q] spat/koniec
[enter] = enter

Dolezite stavy na zapamatanie:

[i] installed, 90% pripadov
 – Ak chcete version pinning, podla mna uz nebudete obycajny uzivatel…

Nechapem co je na tom zlozite. Dokonca pouzitie +/- a oznacenie i pre installed mi pripada nanajvys intuitivne. Ostatne veci sa daju preklikat cez menu.

Trochu mi pripada divne nespomenut aptitudovske vyhladavanie (podla stavu, mena, druhu), ktore je omnoho efektivnejsie ako klasicke regexpy. To by bolo snad aj na samostatny clanok.

Moje prve stretnutie s aptitude (daaavno, veeelmi daaaavno) tiez skoncilo takmer katastrofou a nadavanim na debian, co je to za debilny napad a debilny program… nez som zistil, ze ten program ma aj textove (ne-ncurses) rozhranie. Tak sme sa zrazu skamaratili a po jednom komplikovanejsiom update kde apt-x bolo na palicu a aptitute vyriesil veci za mna siel apt-x do kyticiek uz naveky. Dovtety som videl jedinu vyhodu, ze nemusim pisat apt-cache a podobne ale je to zabalene v jednom prikaze :)

Mylite sa, aptitude vie vyhladavat v popiskoch.

Pouzijete search term ?description(co_hla­date) alebo v skratenej podobe ~dco_hladate .

Referencie: http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03s05.html
a
http://techknack.net/search-apt-package-descriptions/

Ako som spomenul nizsie, o vyhladavani v aptitude by mohol byt celkom pekny clanok alebo tutorial.
Pekny den.

Pletete se, opravuji vás :-).

$ aptitude search "super"|wc -l
23

$ aptitude search ~d"super"|wc -l
213

To první hledá jen v názvech, druhé i v popisech.

Mozete si napriklad nechat vyhladat vsetky nenainstalovane balicky, ktore slovo gimp maju v popisku, ale nie v nazve.

aptitude search „?not(?installed)?not(?n­ame(gimp))?des­cription(gimp)“

Vyhodou je, ze tieto filtre funguju aj v interaktivnom rezime. Staci stlacit notoricky zname / a zadat horeuvedeny string.

pokud vim, tak aptitude neumi preferences, takze je to uplne na 2 veci :)

aptitude install foobar/testing
aptitude -t testing foobar

a tohle ma byt co? umi to parsovat preferences nebo chces jen rict, ze to zna ‚target release‘? jsem to nezkousel, pac to nepouzivam, ale vsude v navodech na apt pinning bylo, ze to aptitude nezvlada.

pokial viem, tak /etc/apt/prefereces to parsuje spravne

Aptitude umí preferences (pinning)

Tak som sa presvedčil, že ostanem u apt-get a spol. Vyhľadávanie pri aptitude vyhľadá iba balíky, ktoré daný reťazec majú v názve, apt-cache prehľadá aj popisy (iste to niekde pôjde zmeniť, ale defaultné search sa chová takto a neviem teraz hneď, ako sa to mení). Skúsme si vyhľadať reťazec irc. V aptitude to napr. x-chat nenájde.
Aptitude curses rozhranie je strašné – to použijem radšej synaptic.
A niekedy siahnem po dpkg (dpkg -L alebo dpkg -S).

Nepochopil som, preco podla prikladov vychadza lepsie aptitude:

aptitude/apt-get search gimp:
je pekne, ze aptitude napise, ci je balicek nainstalovany, aj ked je to casto nepodstatna informacia. Ale odfikne popis (nepomoze ani aptitude search gimp | cat (pomoze –disable-columns)).
Dalej aptitude hlada v nazvoch balickov, nie v popise. Preliezol som manualovu stranku, a nenasiel som, ako toto chovanie zmenit.
Podla mna sa lepsie sprava apt-get.

apt-get/aptitude remove libqtcore4:
Pri apt-get raz odpoviem, ze teda nechcem odinstalovat 27 balickov, vyznam dalsej otazky pri aptitude nechapem.

Moznost vybrat si v curses rozhrani, co z Suggested/Re­commended nainstalovat ma aj dselect (to som uz asi 8 rokov nepouzil). Rychlejsie je v cli mysou skopirovat nazov dalsieho balicku za apt-get install balicek, ak sa rozhodnem take nieco nainstalovat.

Tibor

ps: nevie niekto, ako nastavit firefox, aby pri kopirovani textu mysou (stredne tlacitko), text umiestnil tam, kde je textovy kurzor, a nie graficky?

dselect, really? myslim, ze sa tu nikto nebude priet, ze APT je lepsi nez dselect (aptitude je APT)

Ano dselect. Aptitude a dselect / [S]elect vyzeraju dost podobne. Zavislosti sa (co si pamatam) v dselect riesili na viac krokov. Po oboznameni sa s moznostami dpkg a apt-get som dselect opustil. Problemy so zavislostami nie su az take caste, aj ked pouzivam sid (a nieco z experimental).

Ale jo, ja se klidně bud přít. Mě osobně přijde dselect *mnohem* lepší než apt a než aptitude.

apt používám jenom na „apt-get install“ když chci nainstalovat jeden konkrétní balíček a vím kterej a vím jaké má závislosti, protože je to o trochu rychlejší.

Jelikož je aptitude preferovaný nástroj, tak ho tak cca jednou za rok vyzkouším abych věděl kam už se dostal a zatím jsem se vždy pokorně vrátil k dselectu. Co mi vadí?:

* třídění balíků. Chci vidět nejdříve nové balíky, pak aktualizace a pak ten zbytek. Tohle se dá sice vyladit přes „Pohledy“, ale nebudu na jednom stroji používat program který si vyladím a všude jinde něco jiného co tohle má nastaveno defaultně, takže na všech debianech používam dselect.
* barvy. občas na mě vypadne taková kombinace barev, že se to opravdu nedá vydržet.
* UI jako celek. Aptitude je do očí bijící příklad, programátorského designování. Napíšeme funkci a někam ji umístíme do UI. Usabilita celého programu je nula nula nic. Navíc se mi skoro pokaždé tam podaří spustit instalaci nebo odstranění balíku aniž bych to chtěl. V deselect nejdříve rešíte závislosti a na odstranění nebo instalaci musíte do hlavního menu, vybrat tu akci a pak ji ještě jednout odsouhlasit. Omyl je prakticky vyloučen.
* Proč mám mačkat q místo Esc. Proč?!
* Pokud se něco instaluje kvuli závislostem, tak to chci hned vidět. V aptitude abych furt hlídal pravej roh, jestli tam nenaskočilo podezřele moc mega a pak skočit do preview. Dselect mi to zobrazí hned a buď se mi to líbí nebo si ze seznamu Suggest něco dovyberu nebo to přes ®evert vrátím zpět.

nieco ako toto:

--- Upgradable Packages
--- New Packages
--- Installed Packages
…

len s vymenenymi prvymi dvoma riadkami? vazne?

farby? naozaj? nie su dost kontrastne s pozadim? malo ruzove? alebo co?

UI mi velmi vyhovuje

> V deselect nejdříve rešíte závislosti a na odstranění nebo instalaci musíte do hlavního menu, vybrat tu akci a pak ji ještě jednout

aptitude akoze okamzite zacina instalovat? pouzivam ho roky a nikdy som nic podobne nezazil

Q vs ESC? dochadzaju uz aj uplne stupidne argumenty?

ten posledny bod mi osobne nepripada velmi relevantny. ja si zvolim co potrebujem a potom skontrolujem zmeny, ake sa maju vykonat. ak nechces Recommends, je na to velmi jednoducha naplast v Options/Pre­ferences…

Synaptic je obecně nástavba nad balíčkovacími programi (tedy nejen nad aptem), lze jej použít například i v Mandrivě, která – jak známo – používá balíčkovací systém na základě RPM.

Autoremove – tak jak je implementována nyní – raději moc nepoužívám, a pokud ano, tak velmi opatrně, protože je řešena pouze vzhledem k závislostem s nimiž je obeznámen balíčkovací systém. V ideálním případě by to nebyl problém. Nicméně, já mám na počítači programy o jejichž závislostech nemá balíčkovací systém ani potuchy (vlastní vývoj, nebo balíčky, které jsou vytvořené ze zdrojových kódů – u mě typicky Fox toolkit, ClanLib a Wine. občas i nějaké skripty), takže je schopen mi vyházet balíčky, které používám. Jde to např. vyřešit uzamčením daných balíčků, ale to je práce navíc a nutnost pamatovat na to, v případě, že chcete mít tyto balíčky neustále aktualizované… Další možnost jak to obejít je vytvoření prázdného balíčku, jenž je na všech těchto balíčcích závislý, ale jednak se mi to moc nelíbí a jednak se ani moc nedoporučuje podobné „oblbovací“ balíčky používat. O dost víc by se mi líbil seznam balíčku, z něhož bych si mohl vybrat, které má ignorovat ( pro tuto operaci ), a ostatní by odstranil.

Jinak Aptitude umí všechno co nejrůznější apty? Já docela využívám auto-apt (např auto-apt -run ./configure, který vyhledá a nainstaluje balíky, které jsou vyžadovaný pro kompilaci daného projektu, ale nejsou ještě naistalovány).

Dovolím si vás opravit. Synaptic je nástavba pro APT. Jen a pouze pro APT. To že jej používáte v mandrivě znamená, že máte nainstalován APT4RPM. Nesouvisí to ani s dpkg ani s rpm, a dokonce ani s urpmi nebo čímkoli jiným.

Dík za opravu. Člověk, aby se pořád učil… :)

Aptitude prave nepouziva autoremove v tom smyslu, ze by smazalo vsechny knihovny na kterych nezavisi nainstalovany program. Aptitude si poznamenava pri instalaci balicku, zda byl explicitne nainstalovan uzivatelem a nebo zda byl automaticky nainstalovan jako reseni zavislosti (flag A ve vypisech).

Pri odinstalaci balicku ty automaticky nainstalovane zase smaze. Bohuzel toto neni vlastnost apt a tak michani apt,synaptics… s aptitude tuto „schopnost“ nici.

Samozrejme flag A jde pro jednotlive balicky v GUI prepinat (klavesy ‚m‘ a ‚M‘).

Prave kvuli autoremove pouzivam aptitude i po prechodu na Ubuntu, i kdyz je tu vetsi duraz na Synaptics.

Na instalování apt nebo synaptic, ale na vysekávání ze závislostních pekel jedině aptitude.

Skuste pouzivat debian na starsom stroji a pouzivat aptitude a velmi rychlo prejdete na apt. Kym sa aptitude len nastartuje, tak apt-cache search uz davno vracia vysledok.

Aptitude ma zmysel len pokial robite dist upgrade, ked som prechadzal na squeeze, tak tam si apt vylamal zuby a aptitude to zmakol.

Tento prispevok je samoucelny. Len som chcel upozornit na vyhladavacie funkcie aptitude, ktore su velmi zaujimave a kustomizovatel­nejsie ako klasicky regexp. V clanku o tejto funkcionalite neni snad ani slovo.

+1 diki lidi

Tak umi to i aptitude nebo ne ? :)

Ano, umí. A umí toho mnohem víc.
Nainstaluj si uživatelskou příručku aptitude (aptitude-doc-cs) a najdi si tam „Vyhledávací vzory“

Vidím že tohle je dost neznámá oblast, která vyžaduje další článek. Díky za tip.

Já v podstatě používám apt-get na instalaci a aptitude na uninstall, abych se zbavil všech zbytečností…
Velkej problém je, že když chce člověk odinstalovat blbosti typu Ekiga, Remmina, Empathy apod. tak zároveň s tím musí odinstalovat i gnome-desktop-environment, jenže tím se i všechno ostatní co si ten balíček natáhnulů jako závislost označí pro autoremove. Jenže v Synapticu to nejde nijak odznačit. Takže se musí růčo fůčo označit většina balíků co člověk chce a ručně je jakoby nainstalovat přes Aptitude, aby se ten autoremove odznačil… Nezná někdo nějakej jednodušší způsob?

Jednodušší způsob bude asi používat aptitude na všechno. Od počáteční instalace. Protože každý z nástrojů má vlastní databázi.

Po prvotní instalaci si trochu „pohraju“ s klávesovou kombinací shift+m nad knihovnami a to je asi tak vše co musím udělat nad rámec běžných zvyklostí. Jo, a když potom odinstalovávám nějaký balík, a vidím, že automaticky chce odinstalovat něco, co tam chci podržet, tak zruším příznak pro automatickou instalaci klávesou „m“ a už mi to takhle označený balík automaticky neodinstaluje. Jo, a kdybych náhodou potřeboval někdy podržet předchozí verzi balíku (když se update nepovede, konkrétně oxine a gphotofs momentálně držím ve stable na předchozích verzích), tak tady máme hold a klávesu „=“.

Aptitude má rozšířenou databázi nad databází aptu, takže pokud něco nainstaluješ přes apt, tak závislosti nebudou v aptitude označené jako automaticky nainstalované, stejně tak apt ignoruje v aptitude zakázané verze, ale kombinovat to lze a aptitude si databázi po spuštění sám srovná

Fííha .. takže zamknout/zakázat balíčky a pak s nimi správně pracovat umí jen nadstavba ? takže nějakou rychlovku v komandlajně musím zase dělat nadstavbou ? hmm. to je zcela jiný filosofický přístup.
Na oSuSE je Zypper jediným výkonným engine a nadstavba je opravdu jenom nadstavba, takže v nadstavbě balíčky nějak označené zypper samozřejmě zpracovává správně. Takže zcela nemám problém kombinovat zypper/yast-tui/yast-gui .. a ani by mi nenapadlo, že by to mohlo být jinak ..
Docela uživatele debianu-like dister lituju, že mají tak složitou směsku balíčkovacích manažerů. :-(

Hmm..ale stale neviem, preco by mal niekto, kto pouziva aptitude vobec siahat po apt*. Aptitude ncurses ma ovladanie hrozne, ale aptitude CLI je fajn. Pre BFU je Synaptic, KPackage, Software Centre atd…

konečně to někdo napsal a naprosto souhlasím, každej má používat jeden nástroj na správu balíků a podle toho na co se cejtí ... osobně jedu na všech .deb os vždy aptitude :)

Na tom není nic složitýho :)

Nadstavba je nadstavba, protože přidává funkčnost. U apt/aptitude je to např. zamykání a zakazování balíčků. Stejně jako rpm neumí balíčky stahovat, ale potřebuje něco, co to udělá za něj (YaST, Zypper nebo uživatel+wget), apt neumí balíčky zamykat a pro správu balíčků, kde je potřeba zamykání, je potřeba sáhnout po aptitude (nebo uživatelem ručně říct verzi balíčku, kterou chceš instalovat). Je to normální unixový přístup, každý si použije to, co mu víc vyhovuje

Tak ja som este s apt problem nemal. Fakt nie. Balicky instalujem „po jednom“, teda jednu vec nainstalujem (aj so zavislostami samozrejme), nakonfigurujem, otestujem a az potom idem na dalsiu. Ziadne tazke problemy so zavislostami sa neobjavili, mozno preto, ze vacsinu casu pouzivam stable (bola len jedna pomerne kratka epizodka stable->testing->unstable->prec-s-tym, to bolo len na desktope).
Aj ked zatial som neupgradoval a vzdy som robil novu instalaciu (vzdy to tak nejako vyslo, ze som menil HW alebo som chcel preorganizovat disk, ci som daval virtualizaciu, tak som system vzdy instaloval nacisto).
Zatial mi stacili apt, cron-apt a dpkg. Vobec som nepotreboval aptitude…

U stable a postup po jednom ? No to mas tezky zivot .. to je skoro tak zdlouhave jako instalace aplikaci do windows. Nebo je to ten zvyk ? :-P

Nechapem, co je na tom zdlhave… Neinstalujem predsa uplne vsetky baliky kazdy den (a keby som robil take nieco, tak by to asi bola „seriova vyroba“ a to by som asi isiel cez dpkg –set-selections).
Bezne instalujem iba nejake kniznice, ked zistim, ze nejaku potrebujem, ale tam nie je vobec problem so zavislostami. Ked mame porovnavat s Windoze aplikaciami, tak naposledy som si na desktop instaloval tusim Poedit, ked som potreboval urobit preklad – tak som ho nainstaloval s apt-get install poedit a isiel som prekladat. No a asi mesiac predtym som instaloval e-book reader: apt-get install fbreader a cital som .pdb subor. Ako inak by som to mal robit, ak nie po jednom? Ked som niekedy minuly rok instaloval desktop, tak som predsa nevedel, ze budem pouzivat e-book reader ci Poedit…
A ked instalujem nieco zlozitejsie, nejaku sluzbu na serveri, tak to aj tak treba konfigurovat. Napriklad LDAP server + Kerberos + NFS server: nainstalovat baliky je predsa to najmenej, omnoho viac roboty je s konfiguraciou a testovanim. A to je tiez lepsie robit po jednom.

Ked instalujes jednu aplikaciu, apt ti fetchuje dalsie balicky s potrebnymi kniznicami/zdi­elatelnymi datami automaticky. Takze nie, neinstalujes „po balickoch“. V priklade, ktory si uviedol si apt automaticky mohol dostahovat dalsich (priklad) 20 balickov ako zavislosti, bez toho aby si to explicitne zadal.

Keby si instaloval „po balickoch“, musel by si stiahnut kazdy jeden balicek, ktory je zavislost pre tvoju aplikaciu, samostatne a nasledne instalovat dpkg -i. APT by si v tom pripade vobec nepotreboval.

Myslim, ze prave na toto sarkasticky reagoval prispievatel vyssie. Ale prirovnanie k instalovaniu aplikacii na Windows mi nepripada velmi nestastne. Presnejsie by bolo: instalovat kazdu kniznicu Windowsovej aplikacie samostatne a nakoniec este aj spustitelny subor aplikacie rucne. Kazdopadne, manualna instalacia je zdlhavejsia a clovek si jej na Windowse uzije dost.

Aha… Ja som ale napisal, ze instalujem „po jednom“, nie ze instalujem po jednom. Tie uvodzovky znamenali, ze to nemyslim uplne doslovne. Samozrejme, apt casto priinstaluje aj potrebne zavislosti. Napriklad ked som dal apt-get install nfs-kernel-server portmap (ano 2 balicky naraz, ja viem! – ale spolu suvisia, povazujem to stale za „po jednom“), tak sa mi samozrejme priinstaloval aj nfs-common… ale tam ziadne zavislostne problemy nehrozia a potom som aj tak musel nastavovat konfiguracne subory pre nfs-kernel-server i nfs-common (a este aj moduly jadra aj iptables)…
To moje „po jednom“ v uvodzovkach znamenalo, ze instalujem vzdy len jednu sluzbu, ktoru potom poriadne nakonfigurujem a odskusam… a az potom instalujem dalsiu sluzbu. Takze pocet balikov, ktore sa instaluju jednym apt-get, je konzistentny sam so sebou a zavislostne problemy nemavam…

Ale dobre, tie moje uvodzovky neboli dostatocne jasne, toto nedorozumenie beriem na seba :-)

P.S.: Obcas pouzivam aj dpkg -i… To ale spravidla nasleduje kratko po fakeroot make-kpkg… ;-)

Samozrejme jsem pocital s automatickou instalaci potrebnych knihove (win instalak si taky zaridi vsechno sam). Spis nechapu, proc na !stable distru! instalovat APLIKACE po jedne a saskovat kolem kazde z nich ?
Normalne zaskrtnu klidne 15 pozadovanych aplikaci, install .. a za chvili tam jsou.

používám dselect někdy od roku 2000, nikdy žádný problém, podle mě je to jedno, ale v anketě jsem dal apt...