Problem mit portmaster -af wg. deprecated Perl

testit

Well-Known Member
Hallo,

ich bin dabei, ein unter Virtualbox laufendes FreeBSD 8.3 auf 8.4 upzugraden.
Lief bislang auch ganz gut, aber nun erscheint nach einem
portmaster -af
den ich wg des Hinweises
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.
abgesetzt habe, nachstehende Meldung:

Code:
===>>> Gathering dependency list for ftp/curl from ports
===>>> Launching child to install lang/perl5.16

===>>> All >> de-freebsd-doc-42697,1 >> docproj-1.17_13 >> netpbm-10.35.89 >> png-1.5.17 >> cmake-2.8.11.2 >> curl-7.32.0 >> lang/perl5.16 (48/48)

===>>> Port directory: /usr/ports/lang/perl5.16

  ===>>> This port is marked DEPRECATED
  ===>>> Unsupported, please upgrade to a more recent version of Perl


  ===>>> If you are sure you can build it, remove the
  DEPRECATED line in the Makefile and try again.

===>>> Update for lang/perl5.16 failed
===>>> Aborting update

===>>> Update for curl-7.32.0 failed
===>>> Aborting update

===>>> Update for cmake-2.8.11.2 failed
===>>> Aborting updated 

===>>> Update for png-1.5.17 failed
===>>> Aborting update

===>>> Update for netpbm-10.35.89 failed
===>>> Aborting update

===>>> Update for docproj-1.17_13 failed
===>>> Aborting update

===>>> Update for de-freebsd-doc-42697,1 failed
===>>> Aborting update

===>>> Killing background jobs
Terminated
===>>> Exiting

Unter /usr/ports taucht bei mir als letzte Version für 8.4 Perl 5.22 auf.

Was ist denn nun zu tun, da offensichtlich der portmaster -af nicht automatisch die letzte Perl 5.22 Version baut?
Sollte ich nun in /usr/ports/lang/perl5.22 wechseln, den Portbau manuell starten und später erneut ein portmaster -af durchführen?

Danke und Gruß
testit
 
Hallo Rob,

vielen Dank!

perl -v zeigt bei mir perl 5.14 an, weswegen ich diese Version nachfolgend eingesetzt habe.

Es hätte mich ja auch schon fast gewundert, wenn so etwas einfach mal problemlos durchlaufen würde.
portmaster - lang/perl5.22 lang/perl5.14
endet mit folgender Meldung

Installing perl5.22-5.22.0_1...
pkg-static: perl5.22-5.22.0_1 conflicts with p5-IO-Compress-2.062 (installs files into the same place). Problematic file: /usr/local/bin/zipdetails
*** Error code 70

Stop in /usr/ports/lang/perl5.22.
*** Error code 1

Stop in /usr/ports/lang/perl5.22.

===>>> Installation of perl5.22-5.22.0_1 (lang/perl5.22) failed
===>>> Aborting update

===>>> Killing background jobs
Terminated

Kann man portmaster ein FORCE / OVERWRITE mit auf den Weg geben?
Habe nichts entsprechendes gefunden.

Danke und Grüße
testit
 
Hi,

IO::Compress ist wohl nun Kernbestandteil, daher einfach das Paket löschen.

# pkg delete p5-IO-Compress-2.062

Rob
 
Hallo Rob,

Du hast mit Deiner Vermutung richtig gelegen!

Leider geschieht bei der Aktualsierung von 8.3 auf 8.4 genau DAS, was bei mir seit Jahren dazu führt, dass ich ungern solche Updates vornehme.
Ständig kommt irgendeine Meldung. Löst man deren Ursache, geht das Spiel von vorne los usw.

Nachdem Perl dann endlich in der neusten Version gebaut wurde und ich mit " portmaster -af" erneut ein Rebuild der Ports anstieß ging es dann so weiter:

===>>> All >> db41-4.1.25_4 (154/154)
]0;portmaster: All >> db41-4.1.25_4 (154/154)
===>>> The databases/db41 port moved to databases/db48
===>>> Reason: Superseded by databases/db48
===>>> Port directory: /usr/ports/databases/db48
===>>> This port is marked DEPRECATED
===>>> Please migrate to db5 or db6
===>>> If you are sure you can build it, remove the
DEPRECATED line in the Makefile and try again.
===>>> Update for db41-4.1.25_4 failed
===>>> Aborting update

Ich frage mich, wieso hier dem User nicht einfach angeboten wird, die empfohlene Migration auf db5 oder db6 anzustoßen?
Stattdessen einmal mehr eine frustrierende "Aborting update"-Meldung!

Habe dann mit pkg delete db41-4.1.25_4 weiter gemacht und erneut portmaster -af ausgeführt, um dann wieder eine der unerträglichen "Aborting Update"-Meldungen zu erhalten:

===>>> Returning to update check of installed ports
===>>> Launching child to reinstall t1utils-1.32
===>>> All >> t1utils-1.32 (170/170)
===>>> Currently installed version: t1utils-1.32
===>>> Port directory: /usr/ports/print/t1utils
===>>> Launching 'make checksum' for print/t1utils in background
===>>> Gathering dependency list for print/t1utils from ports
===>>> Initial dependency check complete for print/t1utils
===>>> Returning to update check of installed ports
===>>> The lang/tcl-modules port has been deleted: Modules are now part of the base Tcl distributions
===>>> Aborting update

Ist ja toll, dass mir mitgeteilt wird:
"The lang/tcl-modules port has been deleted: Modules are now part of the base Tcl distributions"

Ja und? Wenn doch offensichtlich bekannt ist, dass das Ganze nun Bestandteil der Basis-TCL-Distribution ist, gibt es doch keinen zwingenden Anlass, hier abzubrechen?

Wie kann man einen Rebuild der Ports realisieren, der dazu führt, dass man von solchen Meldungen verschont bleibt und einfach stets die letzten Versionen aus den Ports neu gebaut werden?

Ich habe jetzt nach mehreren Stunden an dieser Stelle den Versuch, nach einem Upgrade von 8.3 auf 8.4 die Ports neu zu bauen, abgebrochen.

Falls noch jd. einen Tipp hat, wie ich portmaster zu einem rebuild überreden kann, den er SO durchführt, dass alles auf den letzten Stand gebracht wird, ohne jedes Mal mit einer nervenden Meldung das Update zu "aborten", obwohl das aus meiner Sicht überhaupt nicht zwingend bei jeder Meldung notwendig ist, wäre ich sehr dankbar.

Viele Grüße
testit
 
Für FreeBSD 8.4 ist das durch das inzwischen sehr nahe, endgültige EOL und den schon seit Monaten verständlicherweise schlechten Zustand der Ports nicht mehr relevant. Aber inzwischen mit aktuellen Versionen bekommt 'pkg' solche Dinge eigentlich zuverlässig aufgelöst. Seit Version 1.5 und dem nochmals verbesserten Solver hatte ich auf keinem einzigen System, darunter auch echt übel veraltete mit teilweise 2 Jahre alten Paketen, keine Probleme mehr. Daher rate ich inzwischen auch jedem dazu, Pakete zu nutzen, solange es irgendwie möglich ist. Portmaster hat im Vergleich einfach viel weniger Wissen und kann daher viel weniger selbst entscheiden. Er sieht zum Beispiel nur, dass es die tcl-modules nicht mehr gibt und findet einen Eintrag in MOVED, dass es nun in tcl selbst enthalten ist... Für dich bleibt aber nur die harte Tour: Eine Liste der Pakete erstellen, alles löschen und von vorn. Alles andere macht zu viel Ärger und klappt am Ende doch nicht.
 
Hallo Yamagi,

danke Dir für die Infos!

Ich denke, ich gehe noch einen Schritt weiter und installiere ein frisches FreeBSD 10.1 in der virtuellen Maschine.
Zur Erinnerung: Mir geht es eigentlich nur darum, in einer VM noch ein PHP4 auf fastcgi o.ä.-Basis nutzen zu können.
Aufgrund von Rob´s Hinweisen scheint das ja unter FreeBSD 10.1 durchaus möglich zu sein, was mir bislang nicht klar war.

Ideal wäre natürlich, wenn es für Virtualbox ein fertiges FreeBSD 10.1 mit Apache 2.x, PHP5 und MySQL gäbe.

Falls jd. entsprechende Quellen kennt, würde ich mich über einen Hinweis freuen.

Viele Grüße
testit
 
Vielen Dank, habe ich mir mal gebookmarked. Aktuelle nutze ich aber einiges von denkrobat.de.

Eine fertige VM mit "FAMP" für Virtualbox wäre halt noch ganz nett, um die verlorene Zeit wieder reinzuholen ...

Viele Grüße
testit
 
Für FreeBSD 8.4 ist das durch das inzwischen sehr nahe, endgültige EOL und den schon seit Monaten verständlicherweise schlechten Zustand der Ports nicht mehr relevant. Aber inzwischen mit aktuellen Versionen bekommt 'pkg' solche Dinge eigentlich zuverlässig aufgelöst. Seit Version 1.5 und dem nochmals verbesserten Solver hatte ich auf keinem einzigen System, darunter auch echt übel veraltete mit teilweise 2 Jahre alten Paketen, keine Probleme mehr. Daher rate ich inzwischen auch jedem dazu, Pakete zu nutzen, solange es irgendwie möglich ist. Portmaster hat im Vergleich einfach viel weniger Wissen und kann daher viel weniger selbst entscheiden. Er sieht zum Beispiel nur, dass es die tcl-modules nicht mehr gibt und findet einen Eintrag in MOVED, dass es nun in tcl selbst enthalten ist... Für dich bleibt aber nur die harte Tour: Eine Liste der Pakete erstellen, alles löschen und von vorn. Alles andere macht zu viel Ärger und klappt am Ende doch nicht.

Ich habe gerade wieder eine Odyssee hinter mir mit dem Bauen von Virtualbox 4.3.30 unter FreeBSD 10.1.
Nach gefühlten Hunderten von Optionsfenstern, die ich quittieren musste, kam dann nach Stunden eine Fehlermeldung.

Code:
10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

cd /usr/ports/emulators/virtualbox-ose
make install clean

install: dst path '/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.30/out/freebsd.amd64/release/bin/sdk/installer/vboxapi/__init__.py'
kBuild: xsltproc Python constants - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.30/src/VBox/Main/glue/constants-python.xsl
kBuild: Installing /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.30/out/freebsd.amd64/release/bin/sdk/bindings/glue/java/TestVBox.java
kBuild: Installing /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.30/out/freebsd.amd64/release/bin/sdk/bindings/glue/java/Makefile
kmk: *** No rule to make target `/usr/src/sys/kern/bus_if.m', needed by `/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.30/out/freebsd.amd64/release/obj/FreeBSDGeneratedKernelHeaders/bus_if.h'.  Stop.kmk: *** Waiting for unfinished jobs....kmk: *** Exiting with status 2*** Error code 2Stop.make[1]: stopped in /usr/ports/emulators/virtualbox-ose

Offensichtlich fehlen die Kernel-Sources.

Insofern ist Dein Tipp in Bezug auf die bevorzugte Nutzung von Paketen sicher ein weiser Rat.
Allerdings habe ich doch dann keine Möglichkeit mehr, Optionen individuell zu gestalten, wie bspw. bei Virtualbox x11-Support zu deaktivieren.
Oder sehe ich das falsch?

Viele Grüße
testit
 
Genau. Wenn du fertige Pakete nimmst, kannst du keine Optionen abwählen. Du kannst allerdings einzelne Ports selbst bauen oder du setzt einen eigenen Paketserver mit Poudriere auf.
 
Danke für die Klarstellung!

Kann man vor der Installation eines fertigen Paketes herausfinden, mit welchen Optionen es erzeugt wurde?

Grüße
testit
 
Zurück
Oben