RE: Port - Downgrade oder...?

From: Benjamin Thelen \(CCGIS\) <thelen(at)ccgis.de>
Date: Thu, 26 Jun 2003 11:36:31 +0200

Moin,

> -----Original Message-----
> From: Jens Rehsack [mailto:rehsack(at)liwing.de]
> Sent: Wednesday, June 25, 2003 10:51 PM
> To: Benjamin Thelen (CCGIS)
> Cc: De-Bsd-Questions; Harold Gutch; ticso(at)cicely12.cicely.de
> Subject: Re: Port - Downgrade oder...?
>
>
> On 6/25/2003 7:00 PM, Benjamin Thelen (CCGIS) wrote:
> > Moin Jens,
> >
> > Antworten ziemlich weit unten:
> >
> >
> >
> >> -----Original Message-----
> >> From: Jens Rehsack [mailto:rehsack(at)liwing.de]
> >> Sent: Tuesday, June 24, 2003 8:01 PM
> >> To: Benjamin Thelen (CCGIS)
> >> Cc: De-Bsd-Questions; Harold Gutch; ticso(at)cicely12.cicely.de
> >> Subject: Re: Port - Downgrade oder...?
> >>
> >>
> >> On 6/24/2003 7:07 PM, Benjamin Thelen (CCGIS) wrote:
> >> > Nachtrag:
> >> >
> >> > Ich verstehe es wirklich nicht. Egal, ob ich
> >> > tag=RELEASE_4_7_0 (wie bei Bernds output zu sehen ist) oder
> >> > tag=RELEASE_4_7_0_RELEASE (laut Doku) oder
> >> > tag=RELEASE_4_7 (laut Doku) oder
> >> > tag=RELEASE_4(laut Doku)
> >> >
> >> > verwende, am Ende ist der Ports-Tree leer!!!
> >> >
> >> > Wenn man ein falsches 'label' nimmt, passiert das. Steht
> auch so in der
> >> > Doku:
> >>
> >> Lies nochmal die Mail vom Bernd. Im Zweifel lies dann nochmal das cvs
> >> Online Handbuch, da werden Tags genau beschrieben. Und dann
> lies nochmal
> >> den FreeBSD-Handbuchabschnitt über cvsup und die Tags.
> >>
> >> Wenn Du's dann noch nicht hast, lies es nochmal.
> >>
> >> Ich finde, Bernd's Erläuterung hat es auf den Punkt gebracht, und wenn
> >> Du noch etwas an Begrifflichkeiten erklärt haben willst, lies die oben
> >> genannten Handbücher.
> >>
> >> > -------------------------------
> >> > Warning: Be very careful to type the tag name exactly as shown.
> >> CVSup cannot
> >> > distinguish between valid and invalid tags. If you misspell the
> >> tag, CVSup
> >> > will behave as though you had specified a valid tag which
> >> happens to refer
> >> > to no files at all. It will delete your existing sources in
> that case.
> >> > --------------------------------
> >> >
> >> >
> >> > Aber ich habe doch nun die labels aus der Doku verwendet!?
> >>
> >> Die sind aber nur für src/ und doc/, nicht für ports
> >
> >
> > Letzters habe ich jetzt verstanden. Denke ich :-).
> >
> > Mir ist daher die Aussage Bernds "Auf den Ports sind nur die Releasetags
> > drauf - keine Branchtags" nicht eingängig, da ich nach erneutem
> Lesen der
> > Doku eben gesehen habe, dass ich Aussagen wie "In particular,
> use only tag=.
> > for the ports-* collections" in Variationen mehrfach überlesen
> habe und es
> > somit für Ports immer nur den Zustand 'current' gibt (tag=.).
> >
> >
> >
> >>
> >> > Was mache ich da zum Teufel falsch?
> >>
> >> Du machst, wovon Du glaubst, das es sinnvoll sein müsste, ohne Dich von
> >> guten Argumenten abbringen zu lassen.
> >
> >
> > Antworten setzen öfter Mal ein größeres Wissen voraus und
> fallen daher gerne
> > sehr knapp aus, was somit nicht zur Lösung des Problemes beträgt. Dann
> > können die Argumente auch gut sein. Aber wenn der Fragende die guten
> > Argumente nicht versteht, hilft's auch nichts.
>
> 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.
Plötzlich heißt es, die tags in der Doku sind falsch und die mehrfach von
mir überlesene Aussage :-) ist auch falsch! Also steht in der Dokumentation
offensichtlich richtiger Mist. 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?

>
> > 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.

>
> > Ich lese viel, probiere viel und lasse mir meistens wirklich
> Zeit, bis ich
> > in der Mailingliste nerve. Nicht zuletzt frage ich auch nur
> deshalb an, weil
> > ich weder die man-page, noch die Doku, noch mein FreeBSD-Buch (Absolute
> > BSD/Michael Lucas) und schließlich die Funktionsweise nicht ausreichend
> > verstanden habe. Leider gibt es kein Beispiel ports-supfile zum
> Downgrade
> > und in der FAQ ist auch nichts zu finden gewesen. Somit habe ich
> > offensichtlich auch keine Frage gestellt, die schon 1000x
> beantwortet wurde.
>
> Nun, ich habe nie sowas wie Du jetzt tust, probiert. Und ich habe immer
> 'ports-all tag=.' verwendet. Daher muss es irgendwo gestanden haben.
> Gleich vorweg: Ich unterstelle nicht, Du hast nicht gesucht. Ich
> unterstelle nicht, Du warst nicht hartnäckig. Ich behaupte nur: Ich
> hatte es gefunden. Und ich kann behaupten, dass Dir andere
> Listenmitglieder Verweise auf die entsprechende Handbuchstelle mailten.

Siehe oben 1. Kommentar.

>
> >> > 'src-all' habe ich dann wohl doch falsch verstanden, beinhaltet
> >> natürlich
> >> > nicht 'ports-all' und 'doc-all'.
> >> >
> >> > Um das Desaster wieder zu beseitigen habe ich auf beiden
> Rechnern doch
> >> > wieder 'tag=.' verwendet. Somit scheint der Ports-Tree wieder
> >> in Ordnung zu
> >> tag=. wofür? Für ports-*, src-* und/oder doc-*?
> >
> > Ich musste ja den leeren Ports-Tree wieder auffüllen, was auch
> geklappt hat
> > (also ports-* und doc-*).
> >
> > Frage nebenbei:
> > '/usr/src' braucht man in der Hauptsache, um sich einen
> angepaßten Kernel zu
> > kompilieren? Wenn man diesen Zweig, also 'src-all' aber mit cvsup
> > aktualisiert, dann sind die Quellen ja neuer, als das System.
> Ist da nicht
> > erst ein Systemupdate oder soetwas erforderlich, bevor man sich
> einen Kernel
> > mit neueren Quellen kompiliert?
>
> Dazu steht im Handbuch bei
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-
> edge.html
> alles, was auch ich Dir schreiben könnte.
>
> Nein, Du musst nicht Dein System updaten, um einen neuen Kernel zu
> bauen. Ja, Du musst, wenn Du einen Kernel von neueren Sourcen baust,
> Dein gesamtes System (mittels make world) updaten.

Thanks! Das sollte mir reichen.

>
> >> > 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.

>
> > 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.

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

>
> >> > Es kann doch nicht sein, dass der Ports-Tree eine Einbahnstraße
> >> ist!? Ich
> >> > muss doch auch mal einen älteren Port installieren können. Ja
> >> klar kann ich
> >> > auch ein Package einspielen. Nützt mir aber nichts, weil ich
> >> PHP eben als
> >> > cgi kompilieren muss. Warum '../www/php4-cgi' nicht
> >> funktioniert, wie ich es
> >> > brauche, verstehe ich auch nicht.
> >>
> >> Dann schreib' doch mal genauer, was nicht geht. Ich weiss nicht, was Du
> >> willst. Der port www/php4-cgi funktioniert anstandslos. Was auch immer
> >> Du bei www/mod_php4-4.3.1 an Änderungen vornehmen musstest,
> dürfte damit
> >> obsolet sein.
> >
> > 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 :-).

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?

>
> > 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.

>
> > 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.

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.

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

>
> > Entweder findet sich eine Möglichkeit php-4.3.3RC1 so
> umzubiegen, dass es
> > ohne --with-apxs und mit --with-regex=system kompiliert wird
> oder aber ich
> > muss irgendwie sehen, dass ich wieder mein php-4.3.1 bekomme,
> sonst habe ICH
> > ein massives Problem.
>
> Versuch doch mal www/php4-cgi. Was ist denn an dem Port auszusetzen?

Nichts, außer, dass eben mal alles geändert wurde und ich wie der Ochs vorm
Berg stand. Aber mit dem Port ist alles ok, soweit ich das beurteilen kann.

Gruß & Danke,
Benjamin

>
> > Der Fehler liegt sicherlich bei umn-mapserver, jedoch gab es einen
> > workaround und der funktioniert jetzt halt seit php-4.3.3RC1 nicht mehr.
>
> Give the hint a try.
>
> 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 - 11:35:21 CEST

search this site