PacmanManager (diskuse)

[Jardík]

Doufám, že neparsuješ výstup z pacmana a že používáš knihovnu libalpm. Kdysi jsem zkoušel udělat něco jaky synaptic pro pacmana, ale z libalpm nebylo exportováno pár symbolů (jestli tam ty funkce teda vůbec byly) pro práci s tím jejich propojovaným seznamem. Napsal jsem to na fórum, do bugzily, ale nikdo s to nějak neřešil, tak jsem se na to vykašlal.

[kozzi]

Vsadím se že parsuje .

[kozzi]

protože pokud by chtěl používat knihonu libalpm, taky by musel první vytvořit propojení python a libalpm.

[pepik]

já procházím adresáře /var/lib/pacman/. Zdá se mi to daleko jednodušší

[kozzi]

JJ, já dělal to samé. Protože když jsem psal Kozzimana tak ještě nebyla knihovna libalpm. Dnes bych asi použil tu knihovnu, teda pokud bych to psal v C++, ale pokud bych to psal v ruby nebo python, tak nevim jestli by se miu chtělo tvořit ještě moduly pro ten jazyk ktere by podporovali tu knihovnu.

[pepik]

O libalpm jsem nevěděl. A jak píšeš, že bych ještě musel vytvořit modul na propojení, nevím, asi to nechám jak to mám

[kozzi]

Prostě pro používáni knihoven C/C++ v pythonu musí existovat mezivrstva která to spojí. Například aby jsi mohl používat Qt4 musíš mít nainstalovanej balíček pyqt4. No takže aby jsi mohl používat libalpm tak by jsi potřeboval něco jako pylibalpm. Jenomže pokud vím tak nic takového není takže by sis to musel napsat sám. Vetsinou se tyto moduly pisi v C nebo muzes pouzit tak jako pyqt4 utilitu sip nebo jeste existuje pyrex.

[xm]

Není pravda že by musel psát samostatný C modul do Pythonu. V Pythonu máme už dlouho modul ctypes (od verze 2.5 je dokonce defaultní součástí Pythonu), který umožňuje přímo z Pythonu využívat funkce a datové typy z externích Cčkových knihoven, třeba právě z libalpm.

[kozzi]

No kdysi jsem začal psát taky frontend pro pacman v Qt4 + C++, ale nakonec jsem to zabalil, jelikož jsem zjistil, že většina lidí by gui nijak nepoužívala. Je to dobré možná tak jako přehled balíčků . Jinak použití python + Qt4 je dobrá volba.

[Lu-Tze]

Nezdá se mi, že máš třeba zajištěno, že nebudeš mít víc instancí toho programu spuštěno naráz, což asi není dobré, když tam pracuješ s nějakým souborem "packages.txt". Veškeré cesty máš natvrdo v kódu, to asi taky nebude úplně dobře (natvrdo tam máš i nějaké barvy, bude to ok, když bude mít někdo jiné barevné schéma?).

[pepik]

Pravda. Ještě se zeptám, řeší se to tak, že vytvořím v /tmp něco jako lock který se po vypnutí smaže? Nebo existuje nějaká jiná cesta?

[kozzi]

lock je dobrá volba.

[Michal Vyskočil]

FHS doporučuje použít /var/lock

[pepik]

dík za doporučení doporučení

[Jardík]

Žádný program nemá šanci zajistit, aby běžel pouze jednou. Ani ten, co používá pro komunikaci dbus. Stačí spustit skript, který paralelně spouští 100x Audacious (který přes dbus kontroluje, jestli běží) a párkrát se vám ho spustit podaří. Také nemůžete spoléhat na vytvoření nějakého souboru sloužícího jako zámek. Jeden proces otestuje jestli existuje, výsledek je ne. Teď testuje druhý proces - ne. První proces vytvoří soubor a pak ho klidně přepíše ten druhý.

[Lu-Tze]

Tvoje znalosti nejsou dostatečné, unknown_usere. Zkus si je doplnit.

[Jardík]

Myslíš, že se mýlím? Tak mi to vysvětli, jak to tedy je ...

Nick unknown_user jsem nepoužil ani nepamatuji. Jestli to má být provokace, tak se ti moc nepovedla.

[Käyttäjä 11133]

Možná proto, že doba než se ten druhý proces spustí je různá od nuly a operace otestuj zda existuje soubor se zámkem, pokud ne tak ho touchni je rychlejší, než spuštění procesu.

Možná proto ti to připomíná, aby si nezapoměl ;)

[Kyosuke]

Hmm, já se obávám, že i tady může být klidně race condition. Nicméně vždy existují atomické operace pro synchronizaci procesů - co takhle SysV IPC semafor? Tohle snad "vošulit" nejde.

[Käyttäjä 11133]

race condition

Nemluv na mě sprostě :) Pro další co by nevěděli co to znamená :)

race condition = anomální chování způsobené nečekanými závislostmi v načasování událostí

co takhle SysV IPC semafor

Neznám, neumím, díky za info :)

[Käyttäjä 11133]

SysV IPC

[Josef Kufner]

man ipc

[thingie]

Dvakrát open na stejné jméno by bezpečný být mohl, ne? To si v jádře nějak pohlídat můžou.

[Kyosuke]

Jak to myslíš? Unixy přeci normálně nebrání dvěma procesům otevřít tentýž soubor dvakrát. To už spíš flock() nebo tak něco, viděl jsem řešení pro perlovské skripty, kdy skript zamkl vlastní datovou část (flock(DATA, LOCK_EX|LOCK_NB) or die "Already running.";). Docela ujeté, ale asi to funguje.

[thingie]

Ani s O_CREAT a O_EXCL? Na zámek jsem jako typicky zapomněl.

[Kyosuke]

Jo, takhle by to vlastně mohlo fungovat taky.

[Bluebear]

Pokud ten soubor není na NFS - pak je to poměrně v hýzlu

[Kyosuke]

Tipoval bych, že bude spíš na tmpfs...

[thingie]

Věci jako /var/lock a tak by právě [proto] přes NFS být neměly. Nemůže vždycky všechno fungovat

[Josef Kufner]

Ale zamykání po NFS funguje Sice je potřeba používat kernelí server a ne ten v user space, ale funguje to.

[pepik]

Jaké cesty natvrdo konkrétně myslíte? Nevim, jak bych jinak mohl řešit podbarvování, snad jedině zjistit barvu aktuálního tématu a přidat k ní např. 30% modrý,... Máte někdo jiný návrh?

[Lu-Tze]

No např. /root/..., pak tam máš asi stokrát /var/lib/pacman. Tohle všechno by asi mělo být v tom zdrojáku na jednom místě, aby to šlo taky jednoduše a jednorázově změnit. Nevím, jestli je někde psáno, že /root je jediný možný adresář pro roota, ale nevím proč by se to nedalo dát změnit. Můžeš sice argumentovat tím, že když takový adresář není, tak ho můžeš vytvořit a celkem nic se nestane, ale co když / bude read-only?

[pepik]

Pravda, opravím

[Kyosuke]

No magic numbers, no magic strings?

[Josef Kufner]

Nacpi to do nějakého konfiguráku. Nemusí to být nic složitého, stačí pár řádek ve tvaru key=value. A samozřejmě volba, kde ten konfigurák má ležet.

[kozzi]

Proč je tam 2x stejnej screenshot?

[pepik]

rád bych ho smazal, ale jak? do správy příloh se nedostanu

[kozzi]

Jaktože?

[pepik]

Už vím, přílohy lze mazat až při publikování článku. Není to bug?

[kotyz]

ma to cenu kdyz mame yapg v qt, gtkpacman v gtk a jacman v jave? nebylo by lepsi vylepsit treba to yapg? ale kdo chce kam ...

[pepik]

Koukal jsem na yapg a podle screenů vypadá dost dobře. Ikdybych třeba PacmanManagera nedodělal, alespoň získám nějaké zkušenosti. Jak jinak bych se měl učit programovat než pracovat na něčem (třeba i zbytečně), co by třeba i jiní lidé používali a kritizovali

[pepik]

Nový PKGBUILD pro Arch. Přidaná ochrana proti více zpuštění, tlačítko Use changes zobrazí provedené úpravy (instalace však ještě není dodělaná), adresy byly dány do samostatného souboru, který v příští verzi bude v /root/.pacmanmanager/.

[Jardík]

Co to dát radši někam do /etc? A pro home dir použij něco jako getenv("HOME") místo pevně nastaveného /root. Můj root má adresář v /Users/root. Ale nevím, jak to je v pythonu, hledej něco s env/environ.

[pepik]

Vůbec by mě nenapadlo, že si někdo dává uživatele do jedné složky. Dík za upozornění. Pokusím se to opravit

[vogo]

Proč to nebudu nikdy nějaký grafický frontend k pacmanovi používat? Protože nic takového jsem nepoužíval ani dříve ve Slackware. Protože pacman je pacman a konzole je konzole, protože pacman se skvěle ovládá, a určitě se jej velmi snadno naučí ovládat i začínající uživatelé. Tyhle grafická klikadla nikdy neumožní využít a správně uchopit všechny schopnosti archovkého balíčkvacího systému. Protože mi připadají nepřehledná, protože práce s nimi je pomalá. Mám pokračovat? Ne prostě nic pro mě ;), kdo chce ať to používá, já budu užívat svého pacmana :D.

[pepik]

Takových reakcí jsem čekal víc. Kdyby Arch byl více zaměřen na začínající uživatele, asi by grafická nadstavba měla větší úspěch. Je to podobné, jako kdybych začal tvořit konzolové utilitky pro Ubuntu. Asi by se taky nechytly. Mně jde spíš o to, abych se naučil programovat.

[vogo]

Potom bych se vrhnul na drobet něco drobet jiného, než managera balíčků – vzhledem ke pomlikovanosti úkolu, protože obsáhnout všechno přehledně a použitelně je velmi obtížné, jak již ukazují ostatní takové pokusy (u archu obvzláště), ale budiž :).

Všechno mi připadá takové na jedno brdo, autor si řekne co je důležité, a kde bude jaké tlačitko, ale stále to je takové bezzubé a nahrazuje to pár příkazů v konzoli, které se za 10 minut naučí každý pomocí pacmana z konzole…

[kozzi]

+1, proto jsem ukončil práce nbe svém gui pro pacmana

[D-Evil]

Všech možností nikdy nevyužijou, na to by nestačilo ani sto zaškrtávátek, vybírátek a dalších klikátek a platí to obecně pro jakejkoliv složitější problém. Ale pokud třeba jednorázově provádim nekonkrétní hledání (dejmetomu hledám cokoliv, co se týká MP3), je pro mě jednodušší hledat to v podobnym programu, než studovat manuál, jak a čim to mám hledat, jak mám vyladit formát výstupu atd.

I proto se na čele oblíbenosti držej distribuce, který jdou uživatelům vstříc a pokud o to nemaj sami zájem, nezatěžujou je zbytečnejma komplikacema. Nemá smysl v tomhle programu hledat konkurenci konzolový verze, je to prostě jenom alternativa, v některejch případech se hodí víc, v některejch míň.

[vogo]

Popravdě mě zatím nenapadlo, kdy by se grafická nadstavba k pacmanovi hodila víc, proto jsem psal, že bych se raději vrhnul na něco jiného. Ano když hledám nějaký soubor tak v konqueroru, find a spol mi k srdci nepřirostl…

[D-Evil]

Myslim, že právě na to vyhledávání je to ideální. V Kubuntu to tak dělám (v Adeptu), těch parametrů, podle kterejch se dá hledat, je docela dost a fakt nemám důvod kvůli tomu studovat manuál od apt, dpkg atd.

[vogo]

Nemyslím si, že by zrovna hledání balíčku pomocí pacmana bylo obtížné…

[Václav "Darm" Novák]

+1

Gui používám jen na vyhledání a mazání nepotřebných balíčků, pokud jich mažu víc najednou.

[kotyz]

mam gui nadstavby pacmana ale nepouzivam je skoro vubec. mnohem vic ocenuji treba pacman-color a pacsearch.

[Creckx]

Prosimtě napiš na jabber cx@jabber.cz , chtěl bych s tebou něco probrat a nikde jsem nenašel kontakt na tebe.

[belisarivs]

Neuvazujes o implementaci AURu? At Archisti nemusi honit pkgbuildy po netu? Jenom by jim nabehl seznam pkgbuildu a bylo by.

Sam jsem Arch chvili pouzival. Je fajn a neco takoveho by se mi tam libilo.

Mimochodem, ja na Debianu pouzivam Synaptic takrka vyhradne. Ano, nepochyti zdaleka vsechny vlastnosti apt, ale je prehledny. Proste si projdu seznam baliku, pripadne jeste rozdeleny do zkupin a vyberu si co chci.

Apt je jasne rychlejsi na pouzivani a primocarejsi, ale Synaptic je super a nedam na nej dopustit.

Pokracuj v praci, nenech se demotivovat. Neco se naucis a nekdo ti za tvou praci urcite nekdy podekuje.

[pepik]

Implementace AURu by nebyla špatná. Bohužel stále není funkční ani základní instalace balíků. Kód je napsán, pouze chybí propojení s Pacmanem. S Creckx-em (včera mi nabídl pomoc) hledáme nějaké řešení. Standartní propojení přez popen neposílá informace o instalaci, takže není možné zobrazovat průběh.

[kozzi]

A ta knihovna na kterou jsem ti daval odkaz pre jabber by nijak nepomohla?

[pepik]

libpypac má závislost na GTK. Našli jsme ještě pyalpm, který ovšem není zdaleka dodělaný. Creckx mluvil s vývojářem tohoto projektu a domlouval se s nim na spolupráci. Určitě dám vědět o dalšim postupu.

[kozzi]

jj pokud by bylo dodelano pyalpm tak by to bylo fajn.

[pepik]

Taky jsem přemejšlel, jestli by vývojáři pacmana nemohli přidat nový přepínač, kterej by vypisoval bez ncursers. Stačil by jen číselný výstup o průběhu instalace. Ale asi by tento patch nevzali.

[kozzi]

Jo, to by bylo nejsnazsi reseni(pokud by to prijali). Jinak prohledal jsem co se dalo, ale ncurses proste parsovat nejde. U gtk pacman se zobratuje virtualni terminal a vnem vypis z pacmana, coz se mi nelibi. Nevim jak je to u Jacmana, mozna ho prostuduju. Pokud by si se rozhodl jim psat ohledne vylepseni pacmana o ten prepinac tak by take bylo dobre kdyby balicky podporovaly krom stavajicich metadat(nazev, verze,zavislosti,md5sum...) jeste jednu polozku a to category, do ktere by se balicek radil, potom by sed alo do GUI pridat lepsi razeni baliku a nebyla by to takova zmet.

[pepik]

Dobrý nápad. Ale třeba přímo na oficiálních stránkách http://www.archlinux.org/packages/search/?sort=-last_update je u každého balíčku i kategorie, tak nechápu proč to nedaj natvrdo i do balíku.

[kozzi]

JJ, taky nechapu, i u AURu se musi pri zadavani noveho PKGBUILDu zadavat category, tak proc to nemit primo v baliku, alspon toto by mohlo projit.

[juice]

Neuvazujes o implementaci AURu?

mno veď nástrojov, ktoré umožňujú jednoduchú inštaláciu z AURu je tu hneď niekoľko, ja uprednostňujem yaourt, ktorý umožňuje inštaláciu akéhokoľvek balíka z repository alebo AUR transparentne, commandline prepínače sú obdobné ako u pacmana, stačí dať

yaourt -S nazov_balika

a balík sa vyhľadá v repozitároch i v AUR, následne sa nainštaluje/skompiluje, vrátane možnosti editovania PKGBUILD a doťahovania závislostí atď, všetko ľahké, prehľadné a bezpečné (na väčšinu činností nepotrebuje roota)

taktiež funguje prehľadávanie, čiže

yaourt -Ss

a tak ďalej, treba vyskúšať, odporúčam...

pravda, nie je to GUI ale konzolová aplikácia, ale zrovna to mi ani najmenej nevadí

[Václav "Darm" Novák]

Hele, to vypadá elegantněji než aurbuild, díky :)

[kozzi]

+1