portupgrade regt mich auf

fraenki

Active Member
Hallo,

ich habe erst kürzlich bei Updates einiger Rechner von FreeBSD 6.x auf 7.0 unangenehme Erfahrungen mit portupgrade gemacht. Okay, bei einem so großem Release-Update leuchtet mir das ein.

Jetzt habe ich aber heute auf einem (erst kürzlich frisch installiertem) 7.0 das gleiche Problem wieder gesehen. Schaut euch mal an, was beim Update vom Apache passiert ist:

---> Upgrade of www/apache22 started at: Thu, 17 Jul 2008 13:09:07 +0200
---> Upgrading 'apache-2.2.8' to 'apache-2.2.9' (www/apache22)
---> Build of www/apache22 started at: Thu, 17 Jul 2008 13:09:07 +0200
---> Building '/usr/ports/www/apache22' with make flags: BATCH=1 [...]

===> Building for apache-2.2.9 [...]

---> Build of www/apache22 ended at: Thu, 17 Jul 2008 13:12:08 +0200 (consumed 00:03:01)
---> Updating dependency info
---> Modifying /var/db/pkg/GraphicsMagick-nox11-1.1.12/+CONTENTS [...]

---> Uninstallation of apache-2.2.8 started at: Thu, 17 Jul 2008 13:12:11 +0200
---> Fixing up dependencies before creating a package
---> Backing up the old version
---> Uninstalling the old version
---> Deinstalling 'apache-2.2.8' [...]
---> Uninstallation of apache-2.2.8 ended at: Thu, 17 Jul 2008 13:12:22 +0200 (consumed 00:00:11)

---> Installation of www/apache22 started at: Thu, 17 Jul 2008 13:12:22 +0200
---> Installing the new version via the port with make flags: BATCH=1 [...]

===> Installing for apache-2.2.9

===> apache-2.2.9 conflicts with installed package(s):
apr-db42-1.2.12
They install files into the same place.
Please remove them first with pkg_delete(1).
*** Error code 1

---> Installation of www/apache22 ended at: Thu, 17 Jul 2008 13:12:25 +0200 (consumed 00:00:02)
---> Upgrade of www/apache22 ended at: Thu, 17 Jul 2008 13:12:25 +0200 (consumed 00:03:18)

---> ** Upgrade tasks 12: 12 done, 0 ignored, 0 skipped and 0 failed
---> Listing the results (+:done / -:ignored / *:skipped / !:failed)
+ www/apache22 (apache-2.2.8)
[...]
---> Packages processed: 12 done, 0 ignored, 0 skipped and 0 failed

Das ist doch der Hammer, ich fasse mal zusammen:

1.) Ich starte ein `portupgrade -arvb`
2.) Portupgrade kompiliert apache22 fehlerfrei
3.) Portupgrade deinstalliert apache22
4.) Portupgrade prüft Abhängigkeiten, bevor die neue Version installiert wird
5.) Portupgrade erkennt problematische Abhängigkeiten/Konflikte
6.) Portupgrade installiert die neue Version von apache22 NICHT
7.) Portupgrade berichtet das Update von apache22 als FEHLERFREI

Das ist doch wohl der übelste Bug den ich in letzter Zeit gesehen habe.

Genau das gleiche Verhalten zeigt portupgrade übrigens, wenn die pkgdb einen schwerwiegenden Fehler hat (bei mir z.B. mehrfach beim Release-Upgrade von 6.x auf 7.0 passiert, Bugfix ist sehr leicht, einfach fragen).


Ciao
- Fraenki
 
Beim Autor melden? Ich benutze inzwischen nur noch Portmaster. Damit sind mir solche Probleme noch nicht aufgefallen.
 
me too. Portmaster hat sicher auch seine Schwächen, aber alleine die Performance bei vielen installierten Ports, war für mich damals ein Grund umzusteigen.
 
apr wurde von 1.2.x auf 1.3.x umgestellt. Alle Module, die auf apr zurückgreifen, müssen daher neu gebaut werden. Leider ist das in /usr/ports/UPDATING nicht so explizit vermerkt (irgendwo zu subversion schwirrt ein Hinweis rum), und auch portmaster käme damit nicht klar, wenn $admin in dem Falle nicht selbst Hand anlegt:
Code:
portmaster -B -r apr\*
portmaster -auB
 
Ich benutze inzwischen nur noch Portmaster. Damit sind mir solche Probleme noch nicht aufgefallen.

Das habe ich mir auch schon überlegt. Aber ich sehe noch eine Schwierigkeit, die ich bislang nicht lösen konnte. Ich habe eine pkgtools.conf in der die make-Optionen für etwa 600 Ports enthalten sind. Wie ist das bei Portmaster geregelt? Wenn ich die Manpage richtig verstanden habe, nutzt portmaster einfach die "make config" Möglichkeit der Ports, d.h. die make-Optionen werden einfach in /var/db/ports/<portname>/options gespeichert. Damit kann ich leben, aber wie bekomme ich meine bereits vorhandenen 600 make-Optionen dort rein?


Ciao
- Fraenki
 
apr wurde von 1.2.x auf 1.3.x umgestellt. [...] und auch portmaster käme damit nicht klar, wenn $admin in dem Falle nicht selbst Hand anlegt

Teilweise stimme ich dir zu. Wenn es allerdings Imkompatibilitäten gibt, sollte der Port nicht einfach deinstalliert, sondern das Update z.B. nur abgebrochen werden. Das ist IMHO ein schwerwiegender Bug in portupgrade, und es wäre schon ein großer Zufall, wenn portmaster zufällig den gleichen Bug hätte und Ports in diesem Fall auch einfach deinstallieren würde.


Ciao
- Fraenki
 
Was unter /var/db/ports liegt wird mit make config gemacht und sollte schon vorhanden sein. Nur was nicht mit dem Config-Framework gesetzt werden kann musst du manuell in die make.conf übertragen. Alternativ kannst du auch ports-mgmt/portsconf oder buildflags aus sysutils/bsdadminscripts verwenden. Allerdings erspart dir das nicht das Übertragen.
 
Unter portmaster kann man statt der pkgtools.conf direkt die /etc/make.conf verwenden und die entsprechenden Optionen dort setzen.

So long...

Der Indy
 
Ich sag das ja öfters:

Wenn man schon alles updatet, warum nicht einfach erst alles löschen und dann selektiv neuinstallieren. Dann verhindert man auch das ansammeln von Paketleichen.
 
Ich sag das ja öfters:

Wenn man schon alles updatet, warum nicht einfach erst alles löschen und dann selektiv neuinstallieren. Dann verhindert man auch das ansammeln von Paketleichen.
Für Paketleichen gibt es pkg_cutleaves.

Wer sein System regelmäßig pflegt und die Datei UPDATES liest, brauch nicht alles deinstallieren, sondern fährt mit portsnap, portconfig und portupgrade -a im Screen gut.
 
Unter portmaster kann man statt der pkgtools.conf direkt die /etc/make.conf verwenden und die entsprechenden Optionen dort setzen.

Die /etc/make.conf nutze ich gelegentlich, um globale Optionen zu setzen. Aber wie kann ich dort Optionen eintragen, die nur für einen bestimmten Port gelten sollen?


Ciao
- Fraenki
 
z.B. so:

Code:
WITHOUT_X11=yes
WITH_BDB_VER=42
WANT_OPENLDAP_VER=23
WANT_OPENLDAP_SASL=yes

.if ${.CURDIR:M/usr/ports/databases/mysql50-*}
WITH_COLLATION=latin1_german1_ci
WITH_CHARSET=latin1
BUILD_STATIC=yes
BUILD_OPTIMIZED=yes
.endif

.if ${.CURDIR:M/usr/ports/databases/phppgadmin}
PGADMDIR=www/phpPgAdmin
.endif
 
Code:
.if ${.CURDIR:M/usr/ports/databases/mysql50-*}
WITH_COLLATION=latin1_german1_ci
WITH_CHARSET=latin1
BUILD_STATIC=yes
BUILD_OPTIMIZED=yes
.endif

Danke für die Beispiele! Dank der einfachen Syntax sollte es ja kein größeres Problem sein, ein Script zu bauen, dass die alten Einträge aus pkgtools.conf in die make.conf schreibt. Vorher teste ich portmaster aber mal genauer ;-)


Ciao
- Fraenki
 
Ich sag das ja öfters:

Wenn man schon alles updatet, warum nicht einfach erst alles löschen und dann selektiv neuinstallieren. Dann verhindert man auch das ansammeln von Paketleichen.

Und ich wollte das schon öfter mal fragen:

Wie machst Du das denn genau? Mir geht das portupgrade-Gefrickel mitunter ziemlich auf die Nerven. Und portmaster benutzt mE keine Packages.
 
Und ich wollte das schon öfter mal fragen:

Wie machst Du das denn genau? Mir geht das portupgrade-Gefrickel mitunter ziemlich auf die Nerven. Und portmaster benutzt mE keine Packages.
Also einfach pkg_delete -a und dann ein pkg_add -r xorg kde-lite. Dann habe ich schonmal das meiste wiederdrin und bin mir sicher dass das die richtigen Versionen sind. Ein paar Ports wie vlc, mplayer, kmplayer, ogmrip bau ich dann noch von Hand und gut ist.
Nach ein paar Tagen fällt einem noch das eine oder andere Paket ein was fehlt, aber das kann man ja einfach bei Bedarf nachinstallieren...
 
Mir geht das portupgrade-Gefrickel mitunter ziemlich auf die Nerven.
Was genau an portupgrade wird denn "gefrickelt"?

Ich frickele da überhaupt nichts. Es funktioniert einfach. Und ich benutze portupgrade sehr oft.

Wenn ihr mit den FreeBSD-Ports nicht umgehen könnt und keine Lust habt, euch da einzuarbeiten, dann verwendet Pakete, benutzt keinen Portmanager, sondern nur make, oder wechselt die Distribution oder die OS-Familie.
 
Also einfach pkg_delete -a und dann ein pkg_add -r xorg kde-lite. Dann habe ich schonmal das meiste wiederdrin und bin mir sicher dass das die richtigen Versionen sind. Ein paar Ports wie vlc, mplayer, kmplayer, ogmrip bau ich dann noch von Hand und gut ist.
Nach ein paar Tagen fällt einem noch das eine oder andere Paket ein was fehlt, aber das kann man ja einfach bei Bedarf nachinstallieren...

Danke, das hört sich ja schon mal gut an. Werde ich auch mal so versuchen.
 
@Endorphine:

Entspann Dich mal. Ich benutze portupgrade auch sehr oft. Ich habe geschrieben: mitunter.

Woraus schließt Du denn, dass wir mit den FreeBSD-Ports nicht umgehen können? Und weshalb sollten wir die Distribution oder OS-Familie wechseln?

Möglicherweise ist Dir auch schon aufgefallen, dass viele der hier auftretenden Schwierigkeiten mit den Ports oder portupgrade zu tun haben. Also scheint es ja nicht immer "einfach zu funktionieren". Und ich nehme nicht an, dass es sich immer um Leute handelt, die "mit den FreeBSD-Ports nicht umgehen können".
 
Dank der einfachen Syntax sollte es ja kein größeres Problem sein, ein Script zu bauen, dass die alten Einträge aus pkgtools.conf in die make.conf schreibt.

Ich hab auf die Schnelle mal ein kleines Script gebastelt, das meine alte pkgtools.conf konvertiert. Die Voraussetzungen sind einfach:

1.) im Script den Pfad und Dateinamen anpassen
2.) es dürfen nur noch die MAKE_ARGS in der Quelldatei sein (pkgtools.conf kopieren+anpassen)
3.) die MAKE_ARGS genauso schreiben wie ich ;-)

Beispiel für meine MAKE_ARGS Schreibweise:
Code:
        'ftp/proftpd'                   =>      [
                                                'WITH_LDAP=1',
                                                'WITH_OPENSSL=1',
                                                'WITHOUT_IPV6=1',
                                                'WITH_PAM=1',
                                                ],
        'databases/mysql50-server'      =>      'BUILD_OPTIMIZED=1 BUILD_STATIC=1',

Das Script zur Konvertierung der pkgtools.conf MAKE_ARGS in den OPTIONS-Verzeichnisbaum:
Code:
#!/bin/sh

FILE="/tmp/pkgtools_make_args.conf"
BASEPATH="/tmp/test"
#BASEPATH="/var/db/ports"

option=""
portname=""

while read LINE ; do 
  if `echo $LINE | grep \=\> >/dev/null`; then
  # found options for another port
    # extract port name
    portname="`echo $LINE | cut -d\' -f2 | cut -d\/ -f2`" 
    if [ ! -d "$BASEPATH/$portname" ]; then
      mkdir -p $BASEPATH/$portname
    fi
    echo "# options migrated from pkgtools.conf" > $BASEPATH/$portname/options
    # search for more than one option per line
    echo $LINE|while read pkg delim rest; do 
      if [ "$rest" != "[" ] && [ "$rest" != "''," ] && [ ! -z "$rest" ]; then
        for i in `echo $rest|cut -d\' -f2`; do
          echo $i >> $BASEPATH/$portname/options
        done
      fi
    done 
  else
  # just insert the port options for the current port
    # extract option 
    option="`echo $LINE | cut -d\' -f2`"
    if `echo $LINE | grep \]\, >/dev/null`; then
      # found closing tag => do nothing
    else
      echo $option >> $BASEPATH/$portname/options
    fi
    # reset var
    option=""
  fi
done < $FILE

exit 0

Zuerst hatte ich den Kram in make.conf kompatible Syntax konvertiert, was auch funktioniert. Aber wenn die Options im Verzeichnisbaum unter /var/db/ports liegen kann man das auch ganz leicht in der FreeBSD Tinderbox wiederverwenden :-) Und außerdem bläht sich die make.conf dann nicht auf 17K auf.


Ciao
- Fraenki
 
Zuletzt bearbeitet:
In letzter Zeit favorisiere ich packages und produziere mit Tinderbox vollständige Paketsets bei denen es weniger Überraschungen als bei Source-Updates gibt.

Trotzdem ist das nicht so wirklich zufriedenstellend, gerade im Serverbereich hat man ja einerseits ständig die gleichen Pakete auf den Servern installiert, aber andererseits gibts dann schonmal kleine aber gravierende Unterschiede. Dadurch kommt es dann beim Versuch, die packages über einen Automatismus zu aktualisieren doch immer wieder zu Problemen.

Sowas wie Yum oder Smart package manager, aber für FreeBSD packages, wäre ganz nett. Die von Tinderbox produzierten Paketsets sind dann sowas wie eine eigene "Distribution". Ich würde mir vorstellen, dass man dann solche "Distributionen" für die unterschiedlichen FreeBSD-Servertypen erstellt, und ein yum/smart-ähnliches Tool kümmert sich um die automatischen Updates. Die Updates wurden vorher natürlich getestet, usw.


Ciao
- fraenki
 
Ich benuzte auch portupgrade, möchte aber gern mal portmaster ausprobieren. Im Wiki hier steht das man nicht beides paralell betreiben sollte. Nun meine Frage: Muss ich beim Umstieg von portupgrade auf portmaster irgendwas beachten, bzw. wie kann ich den Umstieg überhaupt realisieren?

Ich hätte jetzt einfach portupgrade deinstalliert und portmaster installiert.....aber bevor ich in Probleme renne wollte ich vorsichtshalber vorher fragen.
 
Ich würde vor dem Wechsel ein mal
# portmaster --check-depends
laufen lassen.

Sonst gibt's da weiter nichts zu beachten.
 
portupgrade/portinstall geht mir leichter von der Hand, leider sind die Optionen bei portmaster ja leicht verschieden und so muß ich denn in der man nachlesen, wie das nun einzusetzen ist und da habe ich meist den portupgrade eben schon getippt.
Wasmir aufgefallen ist: bei portmaster stoppt der Vorgang, wenn ein Fehler auftritt (vermutlich gibt es auch eine Option dafür, weiter zu machen) um dann, wenn der Fehler beseitigt wurde, komplett von neuem loszulegen. portupgrade -a baut erst mal durch, um dann die Fehler zu listen.
portmaster -aD -x openoffice hatte ich da probiert.

Bisher kam ich mit nur Paketen nicht hin. Mal gab es nicht alles, was ich wollte, mal stimmten die Optionen nicht für meinen Bedarf und zuletzt gab es einfach noch keine für meine amd64 Version. Gerade, mit vilen installierten Anwendungen, brauche ich ja ein Verwaltungstool, wie portmaster oder portupgrade. Wenn es nur wenige sind, dann ist das doch leicht von Hand zu erledigen.
 
Wasmir aufgefallen ist: bei portmaster stoppt der Vorgang, wenn ein Fehler auftritt (vermutlich gibt es auch eine Option dafür, weiter zu machen) um dann, wenn der Fehler beseitigt wurde, komplett von neuem loszulegen. portupgrade -a baut erst mal durch, um dann die Fehler zu listen.

Nein, leider kann man portmaster nicht mit auf den Weg geben, dass er Fehler ignorieren soll, da der Autor von Portmaster der Meinung ist, dass, wenn man ein Problem beim Updaten hat, man dieses erst einmal beheben soll, damit die Probleme nicht noch schlimmer werden.

Ich bin da anderer Meinung und deswegen benutze ich anstatt 'portmaster -a' 'portupgrade -a'. Ansonsten bin ich mit portmaster aber vollkommen zufrieden.
 
Zurück
Oben