Portato - A Portage GUI

[Necoro]

WICHTIG: Projekt wurde umbenannt in Portato
[alt]
Vielleicht erinnern sich einige bzw haben es damals gelesen: Es gab/gibt mal das Genetic-Projekt, welches eine Remote-Zugriff für Portage zur Verfügung stellen wollte (damit auch ein GUI). Außerdem sollte das ganze plattform-unabhängig sein etc. Nun ja ... geworden ist es wie immer nix (immer mehr Leute hatten keine Lust mehr, bis nur noch ich übrig blieb) - weswegen ich beschlossen hab, das ganze als Single-User-GUI (das Remote-Zeugs kann man ja immer noch reinbauen, wenn der Rest da ist) unter dem Namen Genetic/One weiterzuführen. Es ist aber im Moment noch nicht sooo weit fortgeschritten - außer Emerge/Unmerge kann es noch nichts ... keine Use-Flags setzen und so... (kommt aber noch =P)

Vorteile gegenüber den GUIs die mir bekannt sind:
- klein
- in Python (keine ewige Kompilierung notwendig)
- benutzt direkt die gentoolkit- & portage-funktionen (--> schnell)

Das wollte ich einfach nur kundtun und damit evtl den ein oder anderen zu finden, der es einsetzen/testen mag --- und evtl auch Mitarbeiter
[/alt]

Homepage: http://necoro.eu/portato/
git branches: git://github.com/Necoro/portato.git git://github.com/Necoro/portato-overlay.git
"offizieller" engl. Thread im Forum: http://forums.gentoo.org/viewtopic-t-502350.html

Anmerkungen:
- Ja, ich weiß, dass es schon einige andere gibt - aber die gefallen mir nicht
- Ja, ich weiß auch, dass es viele Leute gibt, die kein Portage-GUI mögen - die brauchen sich hier aber nicht zu Wort melden =P

/edit:
Aktuelle Version: 0.14.1
Features:
- emerge/unemerge (auch mit --oneshot)
- masking/keywording
- masking/keywording kompletter Queues
- ändern von useflags
- emerge --sync
- emerge --update [--deep] [--newuse] world
- interaktive emerges möglich
- interaktive suche
- Dialog zur Anzeige der updatebaren Pakete
- Abbruch des Emerge-Vorganges möglich
- ebuild-Anzeige mit Syntax-Highlighting
- Plugin-System
- GTK-Oberfläche
- Systray und Desktop-Menü-Einträge

[Finswimmer]

Code: Select all

[08:44:52]|[root@tobi-rechner]|/home/tobi$geneticone
Traceback (most recent call last):
  File "/usr/bin/geneticone", line 14, in ?
    import vte
ImportError: No module named vte

Ich finde allerdings für python kein vte.

Oder soll ich x11-libs/vte nehmen?

Tobi

[Necoro]

Ups ... ja ... hab die Abhängigkeit vergessen ... ist halt teilweise schwierig im Nachhinein die Dependencies zu finden.. werde das nachher mal fixen

[Necoro]

--> neues ebuild http://prdownloads.sourceforge.net/gene ... d?download


wenn noch mehr Dependency-Fehler da sind, bitte melden

[xraver]

Hallo,
schön und gut das es immer wieder neue Projekte gibt.

Aber was ist an Kuroo so verkehrt? Ich persöhnlich finde emerge in der shell noch am besten, aber Kuroo bietet sehr viele brauchbare Optionen;
- Package Inspector (USE-Flags bestimmen, Versionen ändern)
- Progress bars (wers brauch)
- emerge and etc-update histories
- ..und und und

Gut, diese Programm muss man zwar kompilieren, bietet aber alle Optionen die dein Projekt auch bietet oder mal bieten soll. Dafür ist es aber mittlerweile Recht stabiel und "it works".

Das Rad wird wie bei vielen Projekten neu erfunden - anstatt die Ressourcen zu sammeln.

[Necoro]

Naja ...:
- kuroo ist mir zu KDE orientiert (zB erfordert die Hilfe unbedingt dieses kfmhelp oder wie das heißt) (bitte jetzt keine Flamewars über KDE/Gnome/etc)
- es verwaltet selber ne Datenbank --> Overkill / unnötig
- einige Funktionen fehlten (zu min damals als ich es testete)
- es gab noch so einige nachteile, die ich gerade nicht on the fly wiedergeben kann
- man muss es kompilieren ... und es dauert rel lange (12 min bei 1,6GHz)

[Hilefoks]

- in Python (keine ewige Kompilierung notwendig)

Das halte ich, nun ja, zumindest für eine grenzwertige Aussage. Die compile-Zeit wird ja schließlich nicht nur durch das Programm selbst bestimmt, sondern (u.U. vor allem) durch die Abhängigkeiten. Aber nix für ungut - viel Erfolg mit deinem Projekt!

MfG,
Hilefoks

[Necoro]

- in Python (keine ewige Kompilierung notwendig)

Das halte ich, nun ja, zumindest für eine grenzwertige Aussage. Die compile-Zeit wird ja schließlich nicht nur durch das Programm selbst bestimmt, sondern (u.U. vor allem) durch die Abhängigkeiten.

Nunja ... die einzige größere Abhängigkeit bei Genetic/One ist pygtk. Diese erfordert wiederum GTK. Sollte dieses noch nicht vorhanden sein, erhöht sich natürlich die Compilezeit... aber kuroo braucht kdelibs und qt ^^

Aber nix für ungut - viel Erfolg mit deinem Projekt!

Danke ^^ ... ich warte im moment darauf, dass ich an das pykeyword-projekt komme - denn kann ich mich ans USE/ACCEPT_KEYWORD/MASK-Flag setzen machen

[Necoro]

So ... basis-suche ist auch drinne

ansonsten (weswegen eigentlich der Post): hab die ebuild-version mal auf die offz Versionsnummer für svn-builds (9999) gesetzt:

http://prdownloads.sourceforge.net/gene ... d?download

[Thargor]

Wie sieht das ganze denn aus?

Könntest du (oder jemand der's grad antestet) mal nen Screenshot posten?

[Necoro]

Screenshots:

Hauptfenster mit was in der emerge-Queue

Paket-Fenster mit Details über ein Paket

Aber die Erscheinung kann und wird sich in Zukunft noch ändern. So ist zum Beispiel heute erst das Suchfeld da oben hinzugekommen ... und die Konsole werde ich wahrscheinlich auch irgendwann eher in weiß ändern.

[think4urs11]

genaugenommen ist das ja unsupportete Software, deswegen -> Diskussionsforum

[Klaus Meier]

Kuroo halte ich für absolut unbrauchbar, weil es die Konfigurationsdateien verändert. Jedenfalls so, daß danach kein ufed mehr geht. Ist schon etwas her als ich es probiert habe, habs danach nicht mehr angefaßt. Porthole gefällt mir da viel besser. Aber als Argument für oder gegen ein Paket die Kompilierzeit zu nehmen, halte ich gelinde gesagt, auch für sehr grenzwertig. Kuroo nehme ich nur, wenn ich sowieso schon KDE habe und porthole bei Gnome. Also fällt da doch qt oder gtk nicht mehr ins Gewicht. Und bei sagen wir mal 24 Stunden Kompilierzeit für ein ganzes System als Argument gegen ein Paket zu bringen, es würde 12 Minuten brauchen, dann darf man erst gar kein Gentoo benutzen.

Ansonsten finde ich solche grafischen Tools ganz nett, um mal zu sehen, was im Portage so alles drin ist. Als Normalnutzer hat man bestimmt erst 20% davon mitbekommen. Aber zum Arbeiten bleibe ich da lieber bei der Konsole. Man weiß dann, wozu welche Datei gut ist und was man wo eintragen muß. Wenn man immer nur mit so einem Tool arbeitet, dann lernt man das nicht. Und wenn die grafische Oberfläche mal streikt oder die ganze Kiste, dann hat man meistens nur eine Konsole zum reparieren.

Ist halt wie mit dem grafischen Installer. Da sagen auch viele, Installation per Hand muß sein, damit ich weiß, wie mein System aufgebaut ist.

[Necoro]

http://prdownloads.sourceforge.net/gene ... d?download

Neue ebuild revision neues Glück =P ...

Habe rel viel dran rumgeschraubt ... ... man kann jetzt u.a. suchen ... und USE-Flags editieren kann man auch (aber achtung: ich schreibe diese beim emerge-Vorgang in die /etc/package.use - macht euch sicherheitshalber ein Backup ... es sollte nix passieren - aber man weiß ja nie) - und im Gegensatz zu kuroo lasse ich Comments und Reihenfolge und so unangetastet

demnächst kommt denn noch package.[(un)?mask|keywords] dran ... =) --- und es müssen dringend Preferences eingebaut werden ... und so Standardsachen wie "emerge -NDu world" sind auch wichtig (aber schwer )

Würde mich freuen, wenn sich der ein oder andere das mal anguckt - und vllt auch einen Wunsch oder einen Bug äußert =)

(und btw: wenn jmd mithelfen will, hätte ich auch nix dagegen )

[firefly]

ich hoffe du hast auch daran gedacht das die /etc/portage.* auch verzeichnisse sein können?

[Necoro]

Hab ich ...

[Necoro]

So ... nu gibts Releases... ... Version 0.3.1 ist da ...

Für Details: http://forums.gentoo.org/viewtopic-t-502350.html

[return13]

wenn du so weiter machst probier ich es in den nächsten Relaises mal aus...
nice work

[Necoro]

danke

aber im moment stelle ich halt fest, dass da richtig Arbeit kommt:
- das mit dem Masken/Unmasken ist komplizierter als ich dachte ... im Gegensatz zu den USE-Flags kann ich die nicht on-the-fly ändern ohne in den Portage-Innereien zu wühlen ... was ich vorerst noch ein wenig herausschieben will, da meine Kentnisse über die Vorgänge noch zu begrenzt ist
- emerge --update world ... ich sehe noch keine Möglichkeit, die upzudatenden Pakte herauszubekommen ... außer den emerge-Output zu parsen ... was ich doof finde

Also wird meine Roadmap erstmal so aussehen:
1. Preferences bauen ... ist relativ einfach und macht nich viel kaputt ^^
2.1 Optimieren ... kann schon eher was kaputt machen - bringt mir aber evtl mehr Einsichten in Portage ... vllt lös ich mich auch ein Stück von gentoolkit
2.2 Lade-Fenster bauen - es lässt sich leider nicht alles wegoptimieren ... Portage ist nun mal nicht das schnellste =P
3. Unmasken & Co. einbauen
4. emerge --update world und so Spielereien

[Necoro]

Neues Release: 0.3.2

Nur eine Neustrukturierung des Sourcecodes vorgenommen und kleinere Bugs gefixed ... Preferences kommt demnächst (im Laufe der Woche?)

[Klaus Meier]

Mal ne Frage von einem Dummen. Was muß ich denn genau mit dem Ebuild machen, um das Programm zu erzeugen?

[Necoro]

Ganz einfach (alle folgenden Schritte als root):

wenn noch kein overlay vorhanden ist:
- mkdir /usr/local/portage
- echo 'PORTDIR_OVERLAY="/usr/local/portage"' >> /etc/make.conf

danach:
- mkdir -p /usr/local/portage/app-portage/geneticone
- das ebuild nach /usr/local/portage/app-portage/geneticone speichern
- ebuild /usr/local/portage/app-portage/geneticone/geneticone-0.3.2.ebuild digest
- emerge geneticone

Hinweise:
- /usr/local/portage ist nur ein Vorschlag - kann abgeändert/an vorhandene Overlays angepasst werden
- geneticone-0.3.2.ebuild ist natürlich durch das jeweilige ebuild zu ersetzen:)
- wenn das obige einmal gemacht wurde, reicht in Zukunft: ebuild /usr/[...] digest && emerge geneticone

[Klaus Meier]

Danke, werde es heute nachmittag mal testen.

[Necoro]

So ... ich habe das ganze mal in ein eigenes Overlay gebastelt:

das Overlay findet sich unter https://svn.sourceforge.net/svnroot/geneticone/overlay
das muss man denn nur noch auschecken - das ebuild digest entfällt

noch einfacher: layman benutzen

Code: Select all

layman -o http://portato.sf.net/layman.xml -S && layman -o http://portato.sf.net/layman.xml -a portato

und das Overlay ist auf dem Rechner (und entsprechend by portage registriert)

[Necoro]

hmmm ... merke ... bei der "Konkurrenz" mal in den Sourcecode schauen lohnt sich ... hab mir vorhin mal porthole (0.4.1 --- 0.5.0 ist masked und mir damit zu gefährlich) ... und siehe da: habe bemerkt, dass die portage-funktionen verwenden die um einiges schneller sind, als die, die ich benutze (bzw sie reduzieren den Overhead) ... also diese mal schnell implementiert (und als ich denn auch noch mit der glorreichen "dir()"-Funktion durch die Portage-API gedüst bin hab ich auch noch einige andere kleine Gimmicks entdeckt) ... Außerdem habe ich manche - jetzt teilweise nicht mehr nachvollziehbare - Algorithmen-Sünden behoben --> Resultat: Das laden der Paketlisten ist ein ganzes Stück schneller gegangen ... Da überlege ich glatt, auf den "Lade"-Hinweis zu verzichten
Diese Verbesserung gibts aber nur im SVN ... als Revision kommt sie mit dem nächsten größeren Update

Außerdem durfte ich feststellen, dass mir Porthole auch nicht gefällt (insbesondere bin ich ein Gegner von "Schonmal-im-Vornherein-alles-laden" )