Moin noch mal,
> -----Original Message-----
> From: owner-de-bsd-questions(at)de.FreeBSD.org
> [mailto:owner-de-bsd-questions(at)de.FreeBSD.org]On Behalf Of Jens Rehsack
> Sent: Thursday, June 26, 2003 12:14 PM
> To: Benjamin Thelen (CCGIS)
> Cc: De-Bsd-Questions; Harold Gutch; ticso(at)cicely12.cicely.de
> Subject: Re: Port - Downgrade oder...?
>
>
> 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.
Ich verstehe nicht, was dieses Mail von Harold in Zusammenhang mit meiner
Aussage beantworten soll. Aber ist auch egal, denke ich, sonst verhaspeln
wir uns hier immer weiter.
>
> > 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?
Wie auch immer man das nennt, tag=RELEASE_4_7_0 ist für Ports möglich.
Das funktioniert, wie ich in der Mail an Harold von heute kurz bestätigt
habe.
Wenn das kein tag für Ports ist, weiß ich auch nicht. Somit sind Tags mit
Ports assosiiert und somit sind die Aussagen im offiziellen Handbuch falsch
ist. Oder aber ich vertue mich mit der Nomenklatur, was mir Leid täte,
jedoch funktioniert immerhin genau das, was ich benötigte (auch ohne date).
>
> > 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?
Offensichtlich hast Du die Mail, die ich an Harold geschrieben habe nicht
gelesen. Darin, um es noch mal zu sagen, bestätige ich Bernds (!!) Aussage
in der Mail vom 24.06. 23.33 und Harolds (!!) in der Mail von 24.06. 23.43,
dass die Doku NICHT korrekt ist und bestätige, dass es sehr wohl
funktionierende tags für Ports gibt. Deshalb ist das Handbuch offensichtlich
an dieser Stelle nicht mehr up-to-date. Das ist auch nicht schlimm, nur
komisch und sollte geändert werden.
>
> > 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."
Danke!
>
> Außerdem schätze ich, das der Satz, den Bernd bemängelt hat, dafür da
> ist, das Newbies nicht mit den Tags experimentieren.
Verstehe ich zwar nicht ganz, aber warum sollte man damit nicht
herumexperimentieren. Sofern man eine korrekte Liste von tags hat, kann man
eigentlich nichts falsch machen. Zumindest habe ich das, was ich dringend
brauchte.
>
> >> > 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.
Das ist genau der Punkt. Von wegen hier wird nicht erzogen. Das absolut
erste, was ich gemacht habe, war Deinem (!) Ratschlag zu Folge in der
man-page zu suchen und mir zu erst alles unter CHECKOUT MODE und dann sogar
die komplette man-page durchzulesen, aber eigentlich habe ich keine Lust
mich hier für meine Vorgehensweise rechtfertigen zu müssen, weil ich mir
keiner Schuld bewußt bin, um Silbertablettantworten gebeten zu haben,
insbesondere im Hinblick darauf, dass in dem Handbuch nicht die richtigen
tags stehen und ich das wirklich nicht wissen kann.
Dass ich das date-tag nicht so gern genommen habe, liegt daran, dass ich mit
tag=RELEASE_4_8_0 einen exakt definierten Stand habe. Bei einem Datum, wo
ich noch nicht einmal genau weiß, welches ich nehmen soll, ist das nicht so
exakt definiert. Deshalb habe ich versucht herauszufinden, wie und ob
tag=RELEASE_X_Y_Z funktioniert.
Als (doch noch immer) Newbie frage ich lieber noch mal nach, bevor ich etwas
auf mein System loslasse.
>
> [...]
>
> >> >> > 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'?
Wie schon oben zwei Mal erwähnt, findest Du untenstehendes Beispiel in der
letzten Mail von mir an Harold und die Bestätigung von mir, dass es
funktioniert - ohne date.
Wenn Dir damit nicht auch ein bisschen geholfen ist - wie war das? "Bisher
habe ich überall
gelesen, dass man date= verwenden soll" - weiß ich auch nicht.
*default host=cvsup6.de.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELEASE_4_7_0
*default delete use-rel-suffix
ports-base
ports-www
>
> >> > 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.
Alles klar, thanks!
>
> >> > 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.
Interessant!
>
> Damit hat sich auch Dein patchen von www/mod_php4/Makefile erübrigt.
Hätte ich auch gedacht, aber das ./configure Skript möchte ganz definitiv
--with-regex=system und dieses apxs... nicht haben. Dann funktioniert das
Skript und umn-mapserver läßt sich kompillieren. Somit ist es zwar nett,
dass es diesen Port gibt, aber er hilft mir nichts.
>
> > 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.
Danke!
>
> Mehr zum Erstellen von Ports unter:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/
Ja, reingeschaut habe ich da schon so manches Mal, aber dafür brauche ich
noch bisschen, glaube ich.
>
> >> > 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.
Hm, dann ist mir das nicht klar. --with-regex ist ja doch was anderes
als --with-regex=system? Ich habe mir das ja nicht ausgedacht, sondern es
steht in der Fehlermeldung, dass ich PHP damit kompillieren soll. Da ich
umn-mapserver brauche, tue ich das.
>
> Denn wer '--with-regex=system' verwendet, sollte genau wissen, was er
> tut und wie eventuell auftretende Fehler behoben werden können.
Tja, ich hoffe, die umn-mapserver Leute wissen, was sie tun. Hatte aber
bisher keinerlei Probleme.
>
> >> > 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
Das ist eine Unterstellung, die definitiv falsch ist. Ich habe es probiert
und mapserver hat sich mit oben stehender Fehlermeldung beschwert.
>
> > 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.
Ups, ja das ist missverständlich ausgedrückt. Sorry. --with-regex... habe
ich natürlich nicht anstatt des --with-apxs=... hinzugefügt. --with-regex
habe, wie Du schon selber schreibst, nach Zeile 72 eingefügt.
>
> > 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.
Genau das,
Benjamin
>
> Gruss,
> Jens
>
>
> To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message
>
>
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 - 13:08:40 CEST