apt-Clone oder nicht? (pat - Ports Administration Tool)

U

uripui

Active Member
Hi,

man kann von Debian halten was man will, aber 'apt' finde ich extrem gut gelungen. Ich wuerde mir wuenschen, wenn es sowas Aehnliches auch fuer FreeBSD geben wuerde.

'portupgrade' gefaellt mir nicht, da es einen Rattenschwanz an Dependencies mitschleppt, weil es u.a. mit BDB-Tabellen arbeitet (wozu eigentlich?). Ferner ist es furchtbar langsam.

Irgendwie scheint auch kein Tool die '/usr/ports/INDEX-?' zu nutzen, wo eigentlich alle wichtigen Sachen drinstehen.

Daher habe ich mal (auch aus Langeweile und Spass heraus) 'pat' angefangen. Es ist in Perl geschrieben und hat sonst keinerlei Abhaengigkeiten. D.h. bei einer firschen FreeBSD-Minimalinstallation muss man lediglich Perl nachinstallieren. Ich habe es erst mit Awk probiert, da es beim Basis-System dabei ist, aber Awk ist furchtbar lahmig.

Im Moment kann 'pat' lediglich:
- INDEX-Datei fuer installierte FreeBSD-Version holen
- verfuegbare sowie installierte Ports anzeigen und suchen
- aktualisierbare Ports anzeigen

Fuer die Zukunft plane ich, dass es folgendes kann:
- Ports und deren Abhaengigkeiten installieren (erst durch Pakete; falls Fehlschlag, dann durch Port-Bauen)
- Ports deinstallieren
- Ports einzeln oder Alle upgraden
- nach Dateien in installierten Ports suchen
- evtl. Ports, die von keinem anderen Port mehr benoetigt werden anzeigen (Leaves)
- evtl. zus. System-Upgrade

<WERBUNG>
warum 'pat':
- es nutzt die INDEX-Datei, welche alle 2h auf 'www.freebsd.org/ports/INDEX-?' neu erstellt wird
- es verwendet seinen eigenen Ports-Tree und aktualisiert nur den Zweig, den er fuer den momentan Port benoetigt
- es ist schnell ? (zumindest bei mir hier. Vor Allem das Abpruefen von neuen Versionen)
- loggt Fehler beim Bauen/Installieren von Ports/Packages in separate Log-Dateien
</WERBUNG>


Besteht da Interesse von Eurer Seite? Der Quellcode ist im Moment im Aufbau und null kommentiert. Leider bin ich kein Perl-Crack und kenne etliche Kniffe nicht, aber es funktioniert zumindest...


Gruss,
Uri
 
Hast du dir schon mal portmgr angesehen?

Was portupgrade betrifft, ich verwende gern:
# pkg_version -Ioql\< | xargs -o portupgrade

statt portupgrade -a.

Ich denke die Abhängigkeiten sind kein Vorteil deiner Software, da portmanager auf Shell-Skripten basierend direkt mit den Mitteln aus dem Basissystem läuft und auch weniger Ressourcen schluckt als portupgrade. Du brauchst schon irgendein Killerfeature, wie in den Abhängigkeiten Zweige zu finden, die parallel bearbeitet werden können um mehrere CPUs zu nutzen ohne make -j zu verwenden. Aber da die möglichkeit mit make -j zu bauen auch irgendwann in die Ports eingebaut wird, relativiert sich das.
 
Von den versch. Tools in 'ports-mgmt' kenne ich bislang richtig nur 'portupgrade' und 'pkg_replace', wobei Letzteres mir noch am besten gefaellt. Die von Euch beiden genannten Tools 'portmanager' und 'portmaster' kenne ich noch nicht.

Macht es denn ueberhaupt Sinn, so viele versch. Ports-Verwaltungs-Tools fuer verschiedene Ports-Verwaltungs-Aufgaben zu haben, wobei mehrere Tools dieselbe Aufgabe erfuellen?

Ich faende es sinnvoller, ein einziges, richtig gutes Tool zu haben, dass Alles erledigen kann. Das kann man dann mit gebuendelter Kraft pflegen und verbessern statt viele kleine Tools zu haben, die jeweils nur ein bisschen koennen.
Oder sehe ich das falsch?

Wie auch immer. Deine Idee mit der parallelen Abarbeitung von 'make'-Prozessen ist auf jeden Fall sehr interessant. Muesste eigentlich sogar mit einem Shell-Skript loesbar sein. Ich denke mal, man faengt mit den Ports an, die keine Dependencies haben oder deren Dependencies alle bereits erfuellt sind und arbeitet sich dann in der Tiefe immer weiter nach vor. Koennte man mit einer Art hierarchischen Warteschlange loesen.

Auf jeden Fall interessanter als mein jetziges 'pat'. Habe ich schonmal was Neues zu basteln. Desegen lasse ich 'pat' jetzt erstmal ruhen...


Danke fuer die Idee und Gruss,
Uri
 
Ups, habe portmaster und portmanager verwechselt. portmaster ist das für das auch öfter mal Anweisungen in /usr/ports/UPDATING auftauchen.
 
Grundsätzlich ist es okay, mehrere Tools für einen Zweck zur Auswahl zu haben. Die einen mögen Opera bspw. lieber als den Firefox und umgekehrt. Bin von portupgrade abgekommen, weil die zusätzliche Datenbank bei vielen installierten Ports sich negativ auf die Performance auswirkt und nicht wie Kamikaze schon geschrieben hat, auf "Boardmitteln" basiert.

Letztlich macht es sicher Sinn, sich die verschiedenen Tools anzugucken und wenn dir die nicht zusagen, schreibst du dir deine Eigenen :).
 
uripui schrieb:
Macht es denn ueberhaupt Sinn, so viele versch. Ports-Verwaltungs-Tools fuer verschiedene Ports-Verwaltungs-Aufgaben zu haben, wobei mehrere Tools dieselbe Aufgabe erfuellen?
Zum Vergrößern anklicken....

Die Portverwaltungstools sind nicht im Basissystem, von daher kann sich jeder installieren und neu erfinden, was er will. Genauso wie es OpenOffice und KOffice etc für die Textverarbeitung gibt.

make ist standardmässig für das Installieren der Ports vorgesehen, alle anderen Tools die eben darauf aufbauen sind Geschmackssache des Anwenders.
 
portmaster ist gestern in Version 2.0 herausgekommen und hat sich zu nem mächtigen Tool gemausert. :)
 
Richtig: Ein offensichtlich neues Feature ist die Übersicht (nach erfolgreichem Durchlauf bei -a), welche Ports einen Upgrade erfahren haben. Das Fehlen dieser Anzeige hat mich schon bei portupgrade genervt (wobei dort eine Liste mit/ohne Upgrade angezeigt wird/wurde?!).

Code: 
[...]

===>>> Done displaying pkg-message files
===>>> The following actions were performed:
        Upgrade of ORBit2-2.14.10 to ORBit2-2.14.11
        Upgrade of gtkmm-2.12.3 to gtkmm-2.12.4
        Upgrade of gcc-4.2.3_20080116 to gcc-4.2.3_20080123
        Upgrade of wine-0.9.53,1 to wine-0.9.54,1

Meine Lieblingsoptions: portmaster -dau :)
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben