Re: Port - Downgrade oder...?

From: Jens Rehsack <rehsack(at)liwing.de>
Date: Thu, 26 Jun 2003 12:13:42 +0200

On 6/26/2003 11:36 AM, Benjamin Thelen (CCGIS) wrote:
>> From: Jens Rehsack [mailto:rehsack(at)liwing.de]

[...]

>> Nun, er könnte auf die Erfahrung der Guru's wie Bernd einfach mal
>> vertrauen und es nicht trotzdem tun. Es ist im allgemeinen besser, aus
>> den Fehlern (bzw. dem Wissen) anderer zu lernen, als jede Erfahrung
>> selbst zu machen.
>
> Nun, da gibt es eine offizielle Dokumentation, in der bestimmte tags
> aufgelistet und ganz klare Aussagen (ports-*: nur tag=.) gemacht werden.

Die Mail von Harold vom 24.06.03 23:27 beantwortet das aber.

> Plötzlich heißt es, die tags in der Doku sind falsch und die mehrfach von
> mir überlesene Aussage :-) ist auch falsch!

Warum ist die von Dir überlesene Aussage falsch? Ich kann Dir nicht
folgen. Auf dem Ports sind keine Tags assoziiert und damit basta. Was
ist daran falsch?

> Also steht in der Dokumentation offensichtlich richtiger Mist.

Harter Tobak, diese Aussage, findest Du nicht? Du hast den wichtigsten
Satz für Dich in der Doku überlesen und alle Deine Versuche mit Tags
schlugen fehl. Der Versuch mit dem 'date', den ich Dir als erste Antwort
gemailt habe, funktioniert nun offensichtlich doch, trotz allen
Widerstrebens deinerseits. Und jetzt steht Mist in der Doku?

> Das ist doch schon wenigstens irritierend,
> eigentlich nicht zu glauben und berechtigt doch schon zu einer weiteren
> Nachfrage, wenn jemand behauptet, in der Doku stünden falsche Informationen.
> Das sollte ganz schleunigst korrigiert werden! Dann wäre nämlich der ganze
> Thread hier nicht nötig gewesen. Wem kann man da Bescheid geben und/oder
> helfen?

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html:

"If you are interested in helping with this project, send email to the
FreeBSD documentation project mailing list."

Außerdem schätze ich, das der Satz, den Bernd bemängelt hat, dafür da
ist, das Newbies nicht mit den Tags experimentieren.

>> > Zur Kommunikation gehören ja wenigstens zwei. Einer der erklärt
>> und einer
>> > der verstehen möchte. Hier ist es durchaus möglich, dass der Erklärende
>> > meint er erklärt verständlich, der Recipient jedoch dennoch
>> nicht versteht.
>> > Das ist durch eine unterschiedliche Herangehensweise an einen
>> Aspekt recht
>> > häufig der Fall.
>> >
>> > Ich denke, dass das häufige Anpflaumen, dass ich in Mailinglisten immer
>> > wieder vorfinde (nicht nur hier), diesen Aspekt nicht außer
>> Acht läßt, was
>> > einen zum Teil recht arroganten Eindruck macht und zum einen weitere,
>> > eigentlich nicht nötige Kommunikation zur Folge hat und zum anderen auch
>> > nicht gerade zur guten Laune beiträgt.
>>
>> Entschuldige, ich wollte Dir nicht zu nahe treten.
>
> Das hat nichts mit zu nahe treten zu tun, sondern einfach ein fehlender
> Respekt und fehlende Höflichkeit dem Gesprächspartner gegenüber zu tun. Wie
> gesagt, das ist mir immer wieder aufgefallen (in anderen Listen/Foren und
> andere Leute betreffend) und dachte einfach nur ui, ui, so hätte ich keinen
> Bock mit mir reden zu lassen. Wir sind doch erwachsene Menschen und brauchen
> uns nicht selber gegenseitig zu erziehen.

Wer hat in diesem Thread versucht, Dich zu erziehen? Es kann gut sein,
dass jemand, der eigendlich recht schwer beschäftigt mit seinem
richtigen Job ist, Dir eine recht knappe Antwort gibt, bei der Du noch
etwas selbst suchen musst und nicht alles auf einem Silbertablett
serviert bekommst.

Ich habe Dir ein Stichwort zur Suche in der Manpage gesandt. Hättest Du
einfach 'man 1 cvsup' eingetippt, und dann nach dem Stichwort gesucht
(geht sogar mit Copy&Paste), wäre Deine Frage sofort beantwortet
gewesen. 'date=...' hinzufügen, 'cvsup -L2 -g dated-cvsupfile' und
fertig wär's gewesen.

Ich kann Deine Bestürzung, die Du hier zum Ausdruck bringst, beim besten
Willen nicht verstehen.

[...]

>> >> > sein. Das bedeutet aber auch, dass ich immer noch nicht an
>> mein älteres
>> >> > PHP4.3.1 herankomme.
>> >>
>> >> date!
>> >
>> > Ok, das zum Thema knapp. :-)
>> >
>> > Was hälst Du davon:
>> > Ich möchte es nicht wieder ausprobieren, dauert furchtbar lang und macht
>> > eventuell den Ports-Tree wieder kaputt.
>>
>> Was hälst Du von: Dann probier es nicht und zieh' Dir die alten Files
>> über's Web-Interface des Ports-Tree's.
>>
>> > *default host=cvsup6.de.FreeBSD.org
>> > *default base=/usr
>> > *default prefix=/usr
>> > #*default release=cvs tag=. date=[cc]yy.mm.dd.hh.mm.ss
>> > *default release=cvs tag=. date=2003.05.01.01.01.01
>> > *default delete use-rel-suffix
>> > ports-base
>> > ports-www
>>
>> Sieht doch sehr gut aus, damit sollte es klappen.
>
> Auch mit date klappt es. Man muss halt etwas probieren, bis man den
> richtigen hat.

Auch? Du hast doch da ein Beispiel mit date stehen. Wieso jetzt
plötzlich 'auch'?

>> > ports-base bin ich mir nicht sicher, es heißt ja, man sollte das immer
>> > verwenden, aber gilt das auch bei einem Downgrade?
>> >
>> > ports-www: Schade, dass man nicht gezielter vorgehen kann, so
>> wir halt das
>> > komplette set www downgegraded, was ja eigentlich nicht nötig ist.
>> >
>> > Danach altes php installieren und dann wieder 'ports-all' ohne 'date='
>> >
>> > Ich würde es ja auch auf meinem Testsystem gleich probieren,
>> aber der ist
>> > seit gestern mit make index && make readmes dran. Ist halt ein
>> PI 120 :-(.
>>
>> Och, dann solltest Du ports/INDEX* in sup/refuse packen. Die Readme's
>> per find(1) genauso.
>
> Hm, das bedeutet ja auch, dass man alle Unterverzeichnisse von www, bis auf
> mod_php4 ins Refuse-File packen kann und ich somit sehr wohl gezielt
> einzelne Ports downgraden kann.

Ja.

> ports/INDEX* ist nicht irgendwie für die Organisation des Ports-Trees
> erforderlich?

Doch, schon. Aber der wird auch nur in regelmäßigen Abständen erzeugt.
Und wenn Du schon ein 'make index' machst, dann überschreib doch Dein
Ergebnis langer harter Rechenarbeit nicht bei der erstbesten Gelegenheit
wieder. Wäre soch sonst Verschwendung.

>> > Ich möchte eine eine Software mit dem Namen umn-mapserver
>> > kompilieren(http://mapserver.gis.umn.edu). umn-mapserver möchte
>> php als cgi
>> > kompiliert haben.
>> >
>> http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0208/msg0
>> 0354.html
>> >
>> > Dazu bearbeite ich /usr/ports/www/mod_php4/Makefile. Dort gibt es
>> > CONFIGURE_ARGS= wo ich '--with-apxs=${PREFIX}/sbin/apxs \'
>> entfernen muss.
>> > Danach läßt sich mapserver fehlerfrei kompilieren.
>>
>> Das ist nun nicht mehr nötig, da www/php4-cgi ein slave-port von
>> lang/php4 ist, der das automatisch für Dich erledigt.
>
>
> Soweit ich mich entsinne wurde lang/php4 nach /www/mod_php4 vor gar nicht so
> langer Zeit umgezogen und jetzt gibt es wieder lang/php4, sowie auch noch
> einen Slaveport www/php4-cgi. Das ist ja ein recht unsteter Port :-).

Der frühere Maintainer vollzog den ersten Schritt. Sehr viele User
bekritelten dass, und so hat der Maintainer gewechselt. Der neue
Maintainer hat nun wieder verschiedene php4-Versionen zur Verfügung
gestellt.

Damit hat sich auch Dein patchen von www/mod_php4/Makefile erübrigt.

> Mir ist die Funktionsweise eines Slaveports nicht klar. Dieser greift beim
> Kompilieren auf seinen Masterport zu? Somit müssen Anpassungen auch im
> Makefile des Masterports vorgenommen werden?

Kommt halt immer drauf an, was Du tun willst. Ein Slave-Port benutzt
einen Master-Port, weil dadurch sehr viele Redundanzen eingespart werden
können. Somit ist es möglich, lang/php4, lang/php4-cli, www/php4-cgi und
www/mod_php4 zu updaten, in dem lang/php4 auf die neueste Version von
php4 gezogen wird. Die Slave-Ports passen sich dann automatisch an.

Üblicherweise nimmt man im Makefile der Slave-Ports nur einige
Änderungen an den Einstellungen des Masters vor und überlässt dem
die eigendliche Arbeit.

Mehr zum Erstellen von Ports unter:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

>> > Als Fehler erhalte ich folgendes:
>> >
>> > !!! The current version of PHP MapScript has some problems with
>> !!!
>> > !!! PHP4's bundled regex. Until we figure the solution to the
>> !!!
>> > !!! problem, the workaround is to compile PHP4 with the system
>> regex !!!
>> > !!! Please re-configure and re-compile PHP4 with
>> --with-system-regex !!!
>> > !!! and then re-configure and re-compile MapServer.
>> !!!
>> >
>> >
>> > Das irritiert an dieser Stelle natürlich, weil es hier um
>> regex=system geht.
>> > Zu Zeiten, als ich noch php 4.3.1 hatte wurde es aber sehr wohl mit
>> > regex=system kompiliert. Es scheint, als hätte sich massiv was zu
>> > php-4.3.3RC1 geändert, denn das Makefile sieht wie schon gesagt
>> total anders
>> > aus, es findet sich der Eintrag
>> > CONFIGURE_ARGS= --with-apxs=${PREFIX}/sbin/apxs \ und der Eintrag
>> > CONFIGURE_ARGS= --with-regex=system gar nicht mehr.
>>
>> Wohl kaum: Siehe http://bugs.php.net/?id=23697 - da weht der Wind her :-)
>
> Die obige Fehlermeldung stammt aber vom ./configure-Skript von umn-mapserver
> und nicht von php und verlangt explizit danach, dass php
> mit --with-regex=system kompiliert wird! Mir scheint, als wäre das an der
> Stelle nicht deutlich gewesen. Außerdem verwende ich kein Apache2 sondern
> 1.3.27.

Oh doch, das war es. Ich wollte Dir nur verdeutlichen, warum statt
'--with-regex=system' jetzt nur noch '--with-regex' im Port steht.

Denn wer '--with-regex=system' verwendet, sollte genau wissen, was er
tut und wie eventuell auftretende Fehler behoben werden können.

>> > Laut info.php wurde php mit folgenden Optionen konfiguriert:
>> >
>> > './configure' '--enable-versioning' '--enable-memory-limit'
>> > '--with-layout=GNU' '--with-zlib-dir=/usr' '--disable-all'
>> '--disable-cli'
>> > '--with-apxs=/usr/local/sbin/apxs' '--enable-ctype' '--enable-dbase'
>> > '--with-dom=/usr/local' '--with-gd' '--enable-gd-native-ttf'
>> > '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
>> > '--with-png-dir=/usr/local' '--with-xpm-dir=/usr/local'
>> > '--with-mysql=/usr/local' '--with-pcre-regex=yes'
>> '--with-pdflib=/usr/local'
>> > '--enable-posix' '--with-pgsql=/usr/local' '--enable-session'
>> > '--enable-tokenizer' '--enable-xml' '--with-expat-dir=/usr/local'
>> > '--with-zlib=yes' '--prefix=/usr/local' 'i386-portbld-freebsd4.7'
>> >
>> >
>> > Da ist ganz offensichtlich ein --with-apxs=/usr/local/sbin/apxs
>> enthalten
>> > und kein --with-regex=system.
>>
>> Nimm vom aktuellen Ports-Tree den port www/php4-cgi. Und verändere ggf.
>> lang/php4 dahingehend, dass er mal '--with-regex=system' verwendet. Geht
>> es dann, gib mir bitte Bescheid.
>
> Wie schon gesagt, mir ist diese Master-/Slaveport-Geschichte völlig neu,
> daher wußte ich auch nicht, dass es lang/php4 wieder gibt und wußte auch
> nicht, dass man dann dort das Makefile bearbeiten muss.

Darum habe ich Dir bereits gleich in der ersten Antwort auf Deine Frage
den Port für die CGI-version des PHP4 mitgeschickt. Du hast sie einfach
nur nicht genutzt und den Hinweis komplett ignoriert. Es hätte Dir auch
egal sein können, ob das ein Slave-Port ist, hauptsache er kompiliert
Dein CGI

> Es sieht aber trotzdem ganz anders aus, als das Makefile von 4.3.1. Habe aus
> CONFIGURE_ARGS+=--with-apxs=${APXS} alles hinter '=' wieder entfernt,
> sowie --with-regex=system hinzugefügt und siehe da, das .configure-skript
> von umn-mapserver läuft einwandfrei durch und mapserver läßt sich wieder
> kompillieren.

Das ist falsch. Du hättest nur '--with-regex=system' hinzufügen
brauchen, und '--with-regex=system' nach der Zeile 72 einfügen müssen.

> Wäre natürlich die Frage, ob das --with-regex=system unter 4.3.3RC1 Probleme
> verursacht oder nur in Zusammenhang mit Apache2!?

Wart es ab und dann frage ggf. beim PHP-Team nach, was Du da tun kannst.

Gruss,
Jens

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 26 Jun 2003 - 12:13:51 CEST

search this site