frage zu portmaster oder portmanager

E

ex-user_4198

Guest
Hallo Leute

Gibt ich hab einen neuen Portstree installiert und möchte nun die installierten Ports upgraden mit Portsmaster oder Portsmanager.
z.B portmanager -u -f

Aber leider tauchen immer wieder diese ncurses Config Menus, mit welchen optionen man ein Port bauen will. Kann man die irgendwie übergehen? Oder so einstellen, dass immer mit den Standart Optionen gebaut wird?

gruss welkin
 
Hallo Welkin.

Aus "man portmaster":
Code:
-u  unattended mode, accepts defaults for all portmaster dialogues
müsste das sein was du suchst, oder?
 
hallo leute

-u This option has been deprecated. It did very little previously, and
not what most users expected. Please check the -d and -D options to
achieve most of the same effect.

Kann man portmaster also nicht mehr mit -u laufen lassen?

Anstatt -u soll man mit option -D/-d Option, dabei werden Distfiles gelöscht (steht in der Manpage). Ist das dass was ich meine? Bin mir nicht sicher.
Wie kann man denn sonst alle Ports (400Stück) ohne ständig diese ncurses Menus zu bearbeiten zu müssen?
 
Ich glaube es gibt so etwas wie BATCH=YES in /etc/make.conf aber da gabs glaube ich auch irgendeinen Haken.
 
ich lass gerade portmaster mit -u -a laufen und die Config Optionen wurden vorher abgehandelt. Mal sehen wie weit ich komme. :) danke leute.
 
Portmaster -u -a ist bei pcre stecken geblieben:


Code:
===>>> Port directory: /usr/ports/devel/pcre
===>>> Starting check for build dependencies
===>>> Gathering dependency list for devel/pcre from ports
===>>> No dependencies for devel/pcre
===> Cleaning for pcre-8.00

===> Vulnerability check disabled, database not found
===> Extracting for pcre-8.00
=> MD5 Checksum OK for pcre-8.00.tar.bz2.
=> SHA256 Checksum OK for pcre-8.00.tar.bz2.
===> Patching for pcre-8.00
/usr/bin/sed -i.bak -e 's/\(pkgconfigdir = \).*/\1$\(DESTDIR\)$\(prefix\)\/li bdata\/pkgconfig/' /usr/ports/devel/pcre/work/pcre-8.00/Makefile.in
===> Configuring for pcre-8.00
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock
===> Script "configure" failed unexpectedly.
Please report the problem to krion@FreeBSD.org [maintainer] and attach the
"/usr/ports/devel/pcre/work/pcre-8.00/config.log" including the output of the
failure of your make command. Also, it might be a good idea to provide an
overview of all packages installed on your system (e.g. an `ls /var/db/pkg`).
*** Error code 1

Stop in /usr/ports/devel/pcre.

===>>> make failed for devel/pcre
===>>> Aborting update

===>>> Update for pcre-7.9 failed
===>>> Aborting update

Bei pcre handelt es sich um die Perl Compatible Regular Expressions library. Was soll ich tun?
 
-u macht bei Portmaster nicht viel, schon gar nicht die Dialoge von `make config` zu unterdrücken; auch eventuelle Messages werden ausgegeben und halten den Upgrade-Prozess so lange an, bis man darauf reagiert. Richtige Batch-Upgrades sind mit Portmaster nicht möglich.
 
PCRE macht immer Probleme. Ich hab das veraltete Paket deinstalliert und dann versucht aus dem aktuellen Portstree pcre zu bauen. Aber ich bekomme immer die selbe Fehlermeldung.

/usr/ports/devel/pcre]# make install clean
===> Configuring for pcre-8.00
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock
===> Script "configure" failed unexpectedly.
Please report the problem to krion@FreeBSD.org [maintainer] and attach the
"/usr/ports/devel/pcre/work/pcre-8.00/config.log" including the output of the
failure of your make command. Also, it might be a good idea to provide an
 
/var/db/ports
enthält für jeden Port die Optionen.
Wenn ein Port sich so ändert, dass er neue Optionen bekommt, wird natürlich auch nachgefragt und die neue Entscheidung entgegen genommen.
Der Eintrag in der make.conf würde dann zwar helfen, aber nur in einer Richtung. Es könnte ja sein, dass du mal anders entscheiden möchtest und deshalb ist so ein Automatismus mitunter nicht ratsam.
Nimmst du hingegen fertige Pakete, sind diese Entscheidungen ja schon getroffen und du brauchst auch keine weiteren Fragen zu beantworten.
Code:
cat /var/db/ports/xine/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for xine-0.99.5
_OPTIONS_READ=xine-0.99.5
WITHOUT_CACA=true
WITH_AALIB=true
WITH_LIRC=true
WITH_CURL=true
WITH_WIN32_CODECS=true
WITH_NLS=true
WITH_XFT=true
Ich bin ja selbst nicht tief drin in dieser Materie, aber dieses Beispiel zeigt die gespeicherten Optionen für eine Version von xine. Die erste gültige Zeile enthält die Versionsinformation und so wird vermutlich das make-script wissen, ob diese Optionen übernommen werden können, oder ob neu nachgefragt werden muss. Hier könnte vermutlich erfolgreich durch ein eigenes Script eingegriffen und diese Optionen automatisch verändert werden. Ich fürchte allerdings, dass dies unüberschaubare Konsequenzen haben kann und für mich selbst habe ich die Entscheidung getroffen, alle Fragen abzuwarten und zu beantworten, auch, wenn damit ein update mal sehr lange dauern kann. Es läuft ja im Hintergrund und stört nicht weiter.
Für die Anpassung der Optionen gäbe es die falsche Methode, einfach die Version anzupassen und alle Optionen so zu lassen und auf ein Gelingen zu hoffen. Ansonsten müssten die möglichen (neuen) Optionen abgefragt, alle Werte automatisch auf "true" gesetzt und so das optionen-file neu gebaut werden, bevor der eigentliche Update anläuft. Das entspricht dem Eintrag "YES" in der make.conf, wie hier schon mal zitiert. Du könntest mit einem solchen vorab-script, das die optionen-files neu schreibt, eigene Entscheidungen an bestimmter Stelle jedoch auch spezifisch setzen und eben die entsprechende Option anders als "true" schalten. Der Aufwand dafür dürfte zwar ziemlich groß sein, aber vielleicht ist das ein machbarer Ansatz.
 
Zurück
Oben