On Sun, Mar 31, 2002 at 09:35:07PM +0200, Ratti wrote:

Hallo,

Wolfram Schlich:

...

ich habe mir Apache 1.3.24 + Geraffel (mod_ssl 2.8.8, mod_perl 1.2.6, PHP 4.1.2) selbst kompiliert. Bis auf mod_perl (als DSO) funktioniert auch alles.

Gerade wenn man am Apache selbst rumschraubt, endet es nach meiner Erfahrung irgendwann im Chaos. Der gebaute Apache von Suse, davon abhängig das Paket mit der Onlinedoku, den eigenen apache drüberkompiliert, dann will man eigene Module reinhängen, dann läufts endlich - bis zum nächsten Update, ...

Ich habe den SuSE-Apache komplett entsorgt. Leider musste dafür auch die Suse-Doku weg, da gab es blöderweise eine Paketabhängigkeit. :-(

Ein wesentlicher Grund war, daß ich die php-pdflib haben wollte, die unterliegt einer nicht GPL-Lizenz, da _muss_ man selbst kompilieren, dafür muss man wieder php neu kompilieren... Gaaa!

Ich habe, wie gesagt, alles gekillt. Dann habe ich mir bei apachetoolbox.com das gleichnamige Tool besorgt, und jetzt kann ich mir meinen apache selbst zusammenstellen. Du wählst in einer Textoberfläche aus, welche Module du haben willst, und er baut ihn dir.

Früher lief das nie, erst seit ich Suses apache wirklich komplett gekickt habe, geht das. Lediglich die RPM-Erstellung läuft nicht, aber das ist problemlos verschmerzbar.

Das einzige, was man noch per Hand machen muss, ist ein paar Softlinks legen, damit die Sachen wieder da liegen, wo Suse sie hinlegt, um möglichst kompatibel zu bleiben.

Hmm, hab ich mir mal angeschaut, gefaellt mir aber nicht. Ist wohl Geschmackssache. Ich will es zumindest mal erfolgreich selbst gemacht haben :-) Wenn SuSE endlich mal neuere Pakete zur Verfuegung stellen wuerde, wenn neue Programmversionen released werden, waere das ja alles halb so wild... aber man hat ja hoechstens backports von bugfixes noetig, grml. -- Wolfram Schlich; Berghof, D-56626 Andernach-Kell; +49-(0)2636-941194;

On Mon, Apr 01, 2002 at 10:01:59PM +0200, Philipp Thomas wrote:

Wolfram Schlich [ Son, 31 Mär 2002 22:42:15 +0200]:

...

Wenn SuSE endlich mal neuere Pakete zur Verfuegung stellen wuerde, wenn neue Programmversionen released werden, waere das ja alles halb so wild... aber man hat ja hoechstens backports von bugfixes noetig, grml.

Unsere Regel lautet, dass es Updates innerhalb einer Distribution nur bei Bugs und Sicherheitsmängeln gibt, allerdings wenn irgendmöglich *keine* neuen Versionen. Mit neuen Versionen holt man sich u.U. nur neue Probleme ins Haus. Das hat nichts mit 'man hat ja höchstens nötig' zu tun, sondern schlicht und einfach mit Pflege der Distribution und einem vernünftigen Handhaben derselben.

Neue Versionen der Pakete gibt es in der Regel nur in einer neuen Distribution. Die sind dann normalerweise schon intern getestet bzw. wurden interne Test-Distributionen damit gebaut. Das hält das Risiko geringer, dass es zu Problemen kommt und ist natürlich auch ein Anreiz für die nächste Distribution ;-)

Mir ist schon klar, warum ihr das so handhabt und prinzipiell bzw. fuer die breite Masse der Anwender sicherlich die beste Loesung. Da ich allerdings davon ausgehe, dass ihr *intern* immer fleissig die neuen Sachen testet und durchaus auch mal fehlerfrei lauffaehige Paketversionen dabei herauskommen, faende ich es schoen, wenn diese zum (selbstverstaendlich auf eigenes Risiko - #include ) Download freigegeben wuerden. Ich habe naemlich einfach keine Lust, staendig auf ftp.suse.com/pub/people rumzusuchen, in der Hoffnung, irgendwo ueber neue Pakete zu stolpern :-) Das resultierte bisher darin, dass ich mir eure SRPMs installiert habe, mir euer ./configure etc. angeschaut und einfach eigene Builds erstellt habe. Ergebnis: inkonsistente RPM-DB (stoert mich zuhause nicht). Und eure spec-files anzupassen macht vielleicht auch keinen Sinn, weil sich $XYZ geaendert hat etc... Waere also schoen, wenn sich die SuSE-Politik in dieser Beziehung dahingehend aendern wuerde, dass neue Paketversionen zumindest an einer Stelle gebuendelt zum Download angeboten werden. Achja btw.- apt: Nutzt SuSE 8.0 nun apt+rpm?! Bin ausserdem schon auf /etc/sysconfig gespannt... -- Wolfram Schlich; Berghof, D-56626 Andernach-Kell; +49-(0)2636-941194;

On Mon, Apr 08, 2002 at 02:42:59PM +0200, Thorsten Kukuk wrote:

On Mon, Apr 08, Wolfram Schlich wrote:

...

Mir ist schon klar, warum ihr das so handhabt und prinzipiell bzw. fuer die breite Masse der Anwender sicherlich die beste Loesung. Da ich allerdings davon ausgehe, dass ihr *intern* immer fleissig die neuen Sachen testet und durchaus auch mal fehlerfrei lauffaehige Paketversionen dabei herauskommen, faende ich es schoen, wenn diese zum (selbstverstaendlich auf eigenes Risiko - #include ) Download freigegeben wuerden.

Ja, natürlich testen wir. Aber glaubst Du, auf den Systemen, wo ich drauf teste läuft noch eine 8.0? Geschweige dann eine 7.3 oder 7.2 oder noch älter? Wir testen auf dem aktuellen System, und die Ergebnisse daraus lassen keinerlei Rückschlüsse auf ältere Versionen zu. Ausserdem, wenn wir Paket A mit shared Libray b als neue Version rausgeben, wer garantiert das dann alle Pakete, die shared Library b brauchen, noch funktionieren? In der Regel gibt es hier meistens den Ärger, und da hilft es Dir gar nicht das Paket A gut getestet ist. Du mußt immer das Komplettsystem mit allen Abhängigkeiten testen.

Hmm... sowas hatte ich schon "befuerchtet" :-)

...

stolpern :-) Das resultierte bisher darin, dass ich mir eure SRPMs installiert habe, mir euer ./configure etc. angeschaut und einfach eigene Builds erstellt habe. Ergebnis: inkonsistente RPM-DB (stoert mich zuhause nicht). Und eure spec-files anzupassen macht vielleicht auch keinen Sinn, weil sich $XYZ geaendert hat etc...

Dann bau doch mit Hilfe der specs wieder neue RPMs? Dann zeigt Dir RPM auch gleich an, welche Abhängigkeiten Du damit alle zerstörst.

Hmm, leider sind die Vorgaenge in den specs nicht kommentiert und somit weiss ich nicht, warum es soundso gemacht wird und ob es nicht fuer mich besser waere, wenn... ;-) Naja.

...

Waere also schoen, wenn sich die SuSE-Politik in dieser Beziehung dahingehend aendern wuerde, dass neue Paketversionen zumindest an einer Stelle gebuendelt zum Download angeboten werden.

Nein, das wird es nicht geben, siehe oben.

Ok, ist verstanden.

...

Achja btw.- apt: Nutzt SuSE 8.0 nun apt+rpm?!

Nein, es ist auch nicht geplant das in Zukunft zu benutzen.

Uhmm, von wem ist dann ftp://ftp.gwdg.de/pub/linux/suse/apt/ ? Von den GWDG-Jungs?

...

Bin ausserdem schon auf /etc/sysconfig gespannt...

Kannst Du jetzt schon haben: mv /etc/rc.config.d /etc/sysconfig; cd /etc; ln -sf sysconfig rc.config.d

Mehr ist das nicht.

LOL, toll... :-) /etc/rc.config bleibt wie gehabt? -- Wolfram Schlich; Berghof, D-56626 Andernach-Kell; +49-(0)2636-941194;

On Mon, Apr 08, 2002 at 04:19:13PM +0200, Peter Wiersig wrote:

On Mon, Apr 08, 2002 at 02:03:38PM +0200, Wolfram Schlich wrote:

...

Achja btw.- apt: Nutzt SuSE 8.0 nun apt+rpm?!

http://apt4rpm.sourceforge.net/home.html#news 25.3.

Warum auf SuSE warten?

Wer sagt was von warten? -> ftp://ftp.gwdg.de/pub/linux/suse/apt/ Rennt hier bisher 1a. Zuerst habe ich alle Pakete von ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/7.3-i386/RPMS.apt4rpm/ installiert, danach eine der Dateien von ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/7.3-i386/examples/ nach /etc/apt/sources.list kopiert, "apt-get update" und "apt-get check" ausgefuehrt. Ganz nett ist auch http://bazar.conectiva.com.br/~godoy/apt-howto/ -- Wolfram Schlich; Berghof, D-56626 Andernach-Kell; +49-(0)2636-941194;