Port der Woche reloaded

Durandal

Marathon4ever
Hallo,

heute möchte ich auf einen neuen Port aufmerksam machen der anscheinend im Board noch unbekannt ist: portmaster
Dieses Programm ist relativ neu im Portstree. Nun zu der Funktion, ich nehme erst mal den Auszug aus der manpage:

The portmaster utility is a simple tool for managing your ports. It uses
no external database to track what you have installed, rather it uses the
existing ports infrastructure, including what is located in /var/db/pkg.
The focus of this tool is to keep the dependency tracking information for
your ports up to date, which allows you to update a specific port without
having to update all of the ports ``above'' it. In the rare case where
you do need to recompile ports which depend on a port you are updating,
the -r option exists to accomplish this. By default portmaster will
first recurse through the port to update, and all of its dependencies (if
any) to handle any port OPTIONS via the 'make config' interface. It will
then start building all ports that need updating. While recursing
through dependencies, a 'make checksum' process will be launched in the
background to either verify that the correct distfiles are available, or
start downloading the new ones.

Also im Klartext:
Das Tool kann einen Port updaten ohne die darüber liegenden Ports mit upzudaten.
So erspart man sich das lästige kompilieren. Bemerkenswert ist die Hash-Funktion welche noch fehlende distfiles parallel besorgt.

Da ich im Portsbereich nicht so der Experte bin kann vielleicht noch jemand Erfahreneres ein-zwei Anmerkungen machen.

Für mich klingt der Port auf jeden Fall interessant und da er im Board noch nicht einmal erwähnt wurde wollte ich ihn hier mal vorstellen.

Viele Grüße,
Durandal
 
Klingt interessant, aber führt das nicht früher oder später zu Abhängigkeitsproblemen?
Irgendwie ist mir da portmanager lieber, trotz langen Kompilierzeiten.

Edit:
> In the rare case where you do need to recompile ports which depend
> on a port you are updating, the -r option exists to accomplish this.
Ist dieser Fall wirklich so selten? Ich dachte, das sei of jeden Fall sinnvoll.
 
Dinh said:
Edit:
> In the rare case where you do need to recompile ports which depend
> on a port you are updating, the -r option exists to accomplish this.
Ist dieser Fall wirklich so selten? Ich dachte, das sei of jeden Fall sinnvoll.
Eigentlich nur wenn die shared library einen Versionsbump hinter sich hatte oder meint das Interface ohne bump ändern zu müssen.
 
Aus der Doku heraus würd ich mal sagen, Verbesserungen gegenüber portupgrade:

1. Parallel downloaden der Distfiles während der erste Port kompiliert
2. recursives konfigurieren der Ports um danach fast schon im BATCH_MODE ablaufen zu können.
3. /bin/sh Skript -> kein ruby

Zweiteres ist toll für alle, die ihre pkgtools.conf nie wirklich angepasst haben bzw dann doch jedes mal alle Ports durchschauen, da sich die Optionen geändert haben könnten.
 
4. kein bdb-ärger, da schon vorhandene Datenbanken genutzt werden

zu 1. Finde ich toll, hätte portupgrade schon lange können sollen
zu 2. das wird portupgrade wohl auch bald können.
zu 3. ruby hat mich bisher daran gehindert portupgrade zu verbessern

Ich bin gespannt, ob/wie ich meine MAKE_ARGS aus pkgtools.conf portiert bekomme.
 
Ja, darauf wird es wohl hinauslaufen. Ich war allerdings bisher kein großer Fan davon die make.conf für die Make flags einzelner Ports zu benutzen...
 
Last edited:
Warum eigentlich nicht? Es hat den Vorteil der universellen Kompatibilität.

Wenn dir die make Syntax nicht gefällt, kannst du auch sysutils/portconf verwenden. Damit kannst du aber soweit ich weiß nicht alles machen, was ich in dem Wiki Beitrag gelistet habe.
 
Der Portmanager find ich eine gute Idee weil dadurch ein Entwichlungsstand bequem gewartet werden kann. Nicht immer kann bei einem Produktivsystem mal eben ein portupgrade durchgeführt werden, da eine jetzt aktuelle Version in naher Zukunft nicht mehr verfügbar ist, aber nicht einfach so umgestellt werden kann.
 
Back
Top