Wer ist hier mit alten Werkzeugen in die FLAVOR Falle reingerannt?

Neues vom Portmaster (via freshports.org)

Add flavor support to portmaster. This version has been lightly tested and
supports upgrades from non-flavored port versions based on the information
in the MOVED file.

For initial installations of flavored ports, the flavor must be specified
as part of the port origin, e.g. "devel/py-py@py36" for the Python-3.6
version of that port. Dependent ports will automatically be installed with
the correct flavor passed via the dependency mechanism.

It is planned to add a --flavor option to ease flavor selection for ports
that are initially installed with portmaster.
 
portmaster hat gerade noch einmal ein Update bekommen: https://svnweb.freebsd.org/changeset/ports/456528

Log:
Add support for ports that have been upgraded with a change of both
origin and package name (sans version), as was the case for e.g. the
lang/cython3 port, which was moved to lang/cython@py36 with a package
name change from cython3-$version to py36-cython-$version.
 
Ich trauere ja immer noch dem alten portupgrade hinterher, was für ein feines Werkzeug das war, für mich war es schlank, flink (im Vergleich zu synth) und ich konnte damit erreichen was ich wollte.

Ich versuche mich mit synth abzufinden, aber ohne etwas Workaround fand ich es für mich bislang unbenutzbar. Liegt einfach daran, dass beim Parallelbuild mehrere Packages so gerne der Herr Murphy kommt, also im unpassendsten Moment die dicksten Dinger gleichzeitig zuschlagen, so etwa Chromium, LibreOffice und vielleicht noch ein llvm. RAM voll, SWAP voll und dann kommt der OOM.

Deswegen habe ich mir was gebastelt, das kann zwar weder den Murphy noch den OOM völlig aufhalten, aber die Wahrscheinlichkeit dass sie sich melden etwas absenken. Ich habe mir da nämlich was gefrickelt, was aus dem alten portupgrade Werkzeug eine Liste erstellt und diese Liste auf die Bedürfnisse von synth anpasst.
So dass beim täglichen bauen nicht mehr ganz so viel auf einmal gebaut werden muss. So wird das Paket Repository vom synth erst nach und nach mit den Paketen gefüllt, jeden Tag ein bisschen mehr, anstatt etwas mehr als 2000 Pakete in einem Rutsch zu versuchen zu bauen. Das habe ich mir dann in die .cshrc als aliase rein gefrickelt:

csh alias um die Bauliste für synth zu machen (für Python FLAVOR py27)
Code:
alias machliste 'portversion -ol "<" | awk '"'"'$1~/py-/ {print $1"@py27"} $1!~/py-/ {print $1}'"'"' > /usr/home/USERl/buildlist && echo " " && cat /usr/home/USER/buildlist'

csh alias um synth dann diese Bauliste einlesen zu lassen, zu bauen und installieren (falls alles gut geht)
Code:
alias synthup   'synth install "`cat /usr/home/USER/buildlist`"'
synth hat nämlich noch eine Angewohnheit, sollte auch nur ein einziges Paket nicht gebaut werden können, wird gleich gar keine Aktualisierung auf dem eignen System durchgeführt. Die Pakete die synth bauen konnte, sind zwar dann im synth Repository, werden aber nicht installiert.

Mit dem Umweg über die buildlist lässt synth sich dann aber austricksen: man editiert die Pakete die nicht gebaut werden können heraus und ruft dann einfach nochmals den synthup alias auf, synth guckt dann ins synth Repository was es schon fertig gebaut hat, die Pakete die synth nicht bauen konnte sind ja dann nicht mehr in der buildlist drin, so dass es dann die Pakete aus dem synth Repository schlussendlich doch noch auf dem eigenem System installiert.
 
Zurück
Oben