Hallo, Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
David Haller schrieb:
Erstmal: dieses und ähnliche Themen gehören _eindeutig_ auf opensuse-programming-de. X-Mailed & F'up dahin.
Sach mal, hast du das überlesen? Das war mehr als nur eine dezente Bitte.
Am Son, 16 Aug 2009, Sebastian Siebert schrieb: [..]
Ich würde dir OBS (openSUSE Build Service) ans Herz legen. https://build.opensuse.org/
Die Pakete kannst du entweder öffentlich zugänglich machen oder auch nicht. Du musst dich nur einmal intensiv mit OBS auseinander setzen. Danach geht es verdammt schnell mit dem Paketbau. *Versprochen* :-)
Naja, nur wenn alles passt. Wenn's mal hakt, dann gerne kräftig.
Wenn du irgendwelche System-Libraries meinst, die im System tief verankert. Dann ja.
Du willst alle nicht-System-Libraries selber mit in deinem OBS-Project mit kompilieren? Das arme OBS.
Falls du mit dem Schreiben einer SPEC-Datei nicht so bewandert bist. Dann würde ich dir empfehlen, eine SPEC-Datei aus irgendeinem OBS-Project zu entnehmen und diese dann anpassen.
Selbst wenn's lokal durchläuft, das rpmlint erfordert meist noch diverse (sinnvolle) Änderungen am Spec oder Patches an den Sourcen und und und. Und das ggfs. je nach SuSE-Version unterschiedlich.
Bisher ist es zu meinen Gunsten gelaufen. Nur Glück oder vom Upstream sauber programmiert, wobei ich eher Letzteres tippe.
Sehr, sehr wahrscheinlich letzteres. _Und_ Glück ;)
Selbst für sehr erfahrene .spec-Bastler wie mich hält das OBS einige unschöne Überraschungen bereit, für deren Behebung man je nach Fall einiges an Erfahrung mit .specs, make (oder was auch immer), und der Programmiersprache braucht.
Besonders spaßig wird's mit Build-Programmen, die sich nicht so einfach wie make auch via (Umgebungs-)Variablen steuern lassen.
Guck dir mal nur die Schweinereien mittels 'sed' in https://build.opensuse.org/package/view_file?file=freemedforms.spec&package=freemedforms&project=home%3Adnh%3Atesting an. Und 'qmake' generiert immerhin noch normale Makefiles.
Ah, David, diese Schweinerei hast du dem Upstream-Autoren zu verdanken, dass diese nicht die notwendige Flexibilität verbauen, dass hat mit OBS wenig zu tun.
Eben. Vom Upstream kommt viel, das "Schweinkram" erforderlich macht. In jeder neuen Version wieder (anders). Aber das OBS verhindert (praktisch), daß man sowas einfach mal systemweit flicken kann, sondern das jedesmal im Spec machen muß.
imake ist auch noch rel. pflegeleicht, dito meist die Perl-Varietäten (Makefile.PL / Build.PL). Bei denen kann man vieles per make VAR= oder zur Not make -e VAR= anpassen.
Meist stehen diese Anpassung in diversen Readme-Dateien oder auf der Webseite vom Upstream, wie man was ändert. Manchmal kann man gar nichts ändern und muss sich mit einigen Patch-Dateien behelfen. Dies ist normal und macht jede andere Distro auch. In diesem Fall muss man sich an das Upstream wenden, um besser Anpassungsfähigkeiten zu ermöglichen.
Ich hab nix gegen patches. Aber nur um $prefix oder LDFLAGS zu ändern?
Aber dann guck dir mal cmake, bjam, IIRC smake, ... an. Da sind irgendwelche Flags für den Compiler hart verdrahtet, oder im besten Fall in irgendwelchen *systemweit gültigen* Files hinterlegt und nicht per Kommandozeile änderbar, die aufgrund irgendwelcher Dinge dann gesetzt werden. Und im OBS kannst du die Systemweiten nicht anpassen! Da kannst du gar nicht so viel fressen wie du kotzen willst.
Wende dich an die Leute vom Upstream. Man kann gar nicht genug wiederholen. :-)
Du meinst, die boost-Leutkens würden wg. mir von bjam auf automake umsteigen?
Die automake / autotools / make mögen ein großer Haufen Dreck sein (so bezeichnen sie einige), aber ich als (u.a.) Paketbauer kann da weitgehend und meist _einfach_ steuern, wie eine bestimmte Datei gebaut wird, dank weitgehend standardisierter Variablen wie CFLAGS, CXXFLAGS, LDFLAGS, DESTDIR usw. Ich ziehe die autotools, trotz der Macken letztlich vor.
Von automake oder autotools sollte man mit Abstand genießen. Da evtl. wichtige Flags überschrieben werden. Hier muss man 3 Mal kontrollieren, ob wirklich alles richtig gelaufen ist.
Ist immer noch viel einfacher. Und überschreiben muß man i.d.R. gar nichtmal, da es bei sauber generierten Makefiles Variablen gibt, über die man gezielt seine Flags reinbringen kann.
Und portabel ist der Kram auch noch. Ich hab mal wget unter Win95 mit den Buildtools vom Visual Studio 4 oder so gebaut. Ging. Einfach so. ./configure, nmake, nmake install (oder install per Hand, weiß nimmer). Shell war IIRC cygwin-bash.
Wenn es keine große Abhängigkeiten gibt, dann haben die vom Upstream gute Arbeit geleistet, dass es wenigstens läuft. :-)
Jup. wget ist sauber.
Und wenn ich mir die ellenlangen Dateien von cmake / bjam in den Verzeichnissen so angucke ... Und wie ewig lang (>>10 min) bjam hier rumeiert, bevor es auch nur das erste Mal den Compiler anwirft (bei libboost), und dann auch noch scheinbar ziemlich kaputte Abhängigkeiten der Sourcen/Objects zu haben scheint ...
Mit libboost kann ich auch was erzählen. Da gab es ein "hash resize" bug, der jetzt behoben wurde. Ich bin für den Paketbau von PokerTH zuständig und dieses Paket benötigt halt libboost. Das PokerTH-Team (Upstream) hat mir mitgeteilt, dass das libboost 1.39 ein Fehler hat.
Oha. PokerTH. Verwende ich...
Wobei der Server von PokerTH abkratzen kann. Hört sich schlimm an, ist aber mit einem Patch schnell behoben. Ich habe bereits ein Fehlerpatch an das OBS-Team der Factory gesendet und habe es eingepflegt. So, und wenn noch was kaputt ist, dann wende dich an das Upstream. (Habe ich das nicht eben schon gesagt?!) In dem Fall war es beim Upstream der Fehler bekannt und ein Patch stand zu Verfügung.
libboost ist IMO v.a. nervig. Nervig zu kompilieren (klappt hier mit keiner bisher probierten 1.3x Version, weder mit gcc-2.93.3, noch 3.3.5), nervig den von diversen Programmen (angeblich) geforderten Versionen hinterherzuhecheln ... AFAIK fluchen auch die Packager der Versionen der OpenSUSE Releases gerne mal über libboost ...
... ist mir ein simples Makefile.am dann doch lieber. Und die Makefile.in / Makefile haben eine wohldefinierte Struktur, die sich aus den Makefile.am ergibt, d.h. auch als Paketbauer reicht es meist nur ins .am zu gucken.
Das wahrlich die einfachste Lösung, wenn der Upstream halt sauber gearbeitet hat.
Bei autotools/automake kann man das recht einfach auch noch per Kommandozeile oder patch (von configure, aclocal.m4, ...) _zentral_ aber lokal, auch im OBS, reparieren, da es eine build-lokale Datei betrifft. Aber wie willst du (als non-root-build) sauber in /usr/{lib,share}/irknwas was patchen?
Äh, *ups*, da bin ich wohl etwas vom Thema abgekommen. Jedenfalls: deine Empfehlung das OBS zu verwenden ist, ähm, etwas eigenwillig.
Ist nicht eigenwillig, sondern man kann es durchaus verwenden. Nur muss man sich wie bei jeder Distro auf Probleme einstellen und mit dem Upstream in Kontakt halten.
Der OP schrieb IIRC nix von nem .spec, das er schon hätte.
Weiß du, welches Paket er meint? Nein. Daher frag ihn doch mal. ;-)
Nö. Und Upstream?
Weiter bitte auf opensuse-programming-de.
Nö, ist für mich hier schon beendet, was ich gesagt habe, habe ich nun gesagt. :-)
Wann'st moanst ... -dnh -- [Der] HTML-Checker findet sich unter http://validator.w3.org/, alles was da nicht durchkommt, ist fehlerhaft und hat im Internet nichts verloren. -- Manfred Tremmel -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Sun, 16 Aug 2009 23:19:19 +0200, you wrote:
AFAIK fluchen auch die Packager der Versionen der OpenSUSE Releases gerne mal über libboost ...
Allerdings :) Das meiste, was ich zum Buildsystem von boost zu sagen habe, ist alles andere als druckreif. Auch die Pflege der Bibliotheken lässt zu wünschen übrig. Da wird einfach auf die aktuellste Version verwiesen und Gut ist. Die Patches darf dann der Packager der einzelnen Distributionen zurückportieren ... Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Philipp Thomas schrieb:
On Sun, 16 Aug 2009 23:19:19 +0200, you wrote:
AFAIK fluchen auch die Packager der Versionen der OpenSUSE Releases gerne mal über libboost ...
Allerdings :) Das meiste, was ich zum Buildsystem von boost zu sagen habe, ist alles andere als druckreif. Auch die Pflege der Bibliotheken lässt zu wünschen übrig. Da wird einfach auf die aktuellste Version verwiesen und Gut ist. Die Patches darf dann der Packager der einzelnen Distributionen zurückportieren ...
Nun ja, ich war wegen dem Update von libboost von der Version 1.38 auf 1.39 auch nicht gerade glücklich. Ich hätte da noch gewartet. Aber eine Rückportierung von libboost auf ältere libbboost Library würde irgendwie kein Sinn machen, höchstens könnte man ein Sammelpatch für die Package-Version 1.39 ansetzten. Was bereits von dem Upstream regelmäßig veröffentlicht wird. Wobei ich mich eigentlich wundere, dass dies bisher noch nicht geschehen ist, sondern nur einzelne Patch, wie man es gerade braucht, eingespielt. Gruß Sebastian -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mon, 17 Aug 2009 02:58:04 +0200, you wrote:
Nun ja, ich war wegen dem Update von libboost von der Version 1.38 auf 1.39 auch nicht gerade glücklich. Ich hätte da noch gewartet.
Der Package Freeze für Basispakete der 11.2 stand kurz bevor. Wenn wir den Update jetzt nicht gemacht hätten, hätte die 11.2 Boost 1.38 verwenden müssen.
Aber eine Rückportierung von libboost auf ältere libbboost Library würde irgendwie kein Sinn machen, höchstens könnte man ein Sammelpatch für die Package-Version 1.39 ansetzten.
Was meinst Du, was ich die letzten Jahre gemacht habe? Grössten Teils Backports von Patchen.
Was bereits von dem Upstream regelmäßig veröffentlicht wird. Wobei ich mich eigentlich wundere, dass dies bisher noch nicht geschehen ist, sondern nur einzelne Patch, wie man es gerade braucht, eingespielt.
Weil ich davon nichts gewusst habe? Weil es keine vernünftige Kommunikation mit den Packagern der verschiedenen Distributionen gibt? Wüsste ich von Sammelpatches, würde ich die mit Handkuss nehmen, auch wenn ich sie dann in Einzelpatches unterteilen würde. Aber wie wäre es, wenn Du dich an der Pflege des Boost-Paketes beteiligen würdest? Jetzt wo Factory offen für alle ist, wäre das ja kein Problem und ich wäre über Hilfe sehr Dankbar. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
David Haller schrieb:
Hallo,
Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
David Haller schrieb:
Erstmal: dieses und ähnliche Themen gehören _eindeutig_ auf opensuse-programming-de. X-Mailed & F'up dahin.
Sach mal, hast du das überlesen?
Das war mehr als nur eine dezente Bitte.
Irgendwie schon... ;-)
Am Son, 16 Aug 2009, Sebastian Siebert schrieb: [..]
Ich würde dir OBS (openSUSE Build Service) ans Herz legen. https://build.opensuse.org/
Die Pakete kannst du entweder öffentlich zugänglich machen oder auch nicht. Du musst dich nur einmal intensiv mit OBS auseinander setzen. Danach geht es verdammt schnell mit dem Paketbau. *Versprochen* :-) Naja, nur wenn alles passt. Wenn's mal hakt, dann gerne kräftig. Wenn du irgendwelche System-Libraries meinst, die im System tief verankert. Dann ja.
Du willst alle nicht-System-Libraries selber mit in deinem OBS-Project mit kompilieren? Das arme OBS.
Nun ja, wie man's nimmt. :-)
Falls du mit dem Schreiben einer SPEC-Datei nicht so bewandert bist. Dann würde ich dir empfehlen, eine SPEC-Datei aus irgendeinem OBS-Project zu entnehmen und diese dann anpassen. Selbst wenn's lokal durchläuft, das rpmlint erfordert meist noch diverse (sinnvolle) Änderungen am Spec oder Patches an den Sourcen und und und. Und das ggfs. je nach SuSE-Version unterschiedlich. Bisher ist es zu meinen Gunsten gelaufen. Nur Glück oder vom Upstream sauber programmiert, wobei ich eher Letzteres tippe.
Sehr, sehr wahrscheinlich letzteres. _Und_ Glück ;)
Jepp...
Selbst für sehr erfahrene .spec-Bastler wie mich hält das OBS einige unschöne Überraschungen bereit, für deren Behebung man je nach Fall einiges an Erfahrung mit .specs, make (oder was auch immer), und der Programmiersprache braucht.
Besonders spaßig wird's mit Build-Programmen, die sich nicht so einfach wie make auch via (Umgebungs-)Variablen steuern lassen.
Guck dir mal nur die Schweinereien mittels 'sed' in https://build.opensuse.org/package/view_file?file=freemedforms.spec&package=freemedforms&project=home%3Adnh%3Atesting an. Und 'qmake' generiert immerhin noch normale Makefiles. Ah, David, diese Schweinerei hast du dem Upstream-Autoren zu verdanken, dass diese nicht die notwendige Flexibilität verbauen, dass hat mit OBS wenig zu tun.
Eben. Vom Upstream kommt viel, das "Schweinkram" erforderlich macht. In jeder neuen Version wieder (anders).
Aber das OBS verhindert (praktisch), daß man sowas einfach mal systemweit flicken kann, sondern das jedesmal im Spec machen muß.
Systemweit geht es aber nicht so einfach. Sonst würden wir ja nur ein floating OS haben, dass ineinander fließt. Wobei wir schon beim Update wohl eher Upgrade auf eine neue glibc schon das gesamte System zum Neubau zwingt. Dann wären wir wieder bei Gentoo und dort wird auch schon wie blöde rumgefrickelt und sämtlich Libraries neuzubauen. Bei Gentoo geht einfach zuviel Zeit drauf, womit man beim OBS "eigentlich" wieder einspart, weil der Normalverbraucher darum nicht mehr kümmern muss.
imake ist auch noch rel. pflegeleicht, dito meist die Perl-Varietäten (Makefile.PL / Build.PL). Bei denen kann man vieles per make VAR= oder zur Not make -e VAR= anpassen. Meist stehen diese Anpassung in diversen Readme-Dateien oder auf der Webseite vom Upstream, wie man was ändert. Manchmal kann man gar nichts ändern und muss sich mit einigen Patch-Dateien behelfen. Dies ist normal und macht jede andere Distro auch. In diesem Fall muss man sich an das Upstream wenden, um besser Anpassungsfähigkeiten zu ermöglichen.
Ich hab nix gegen patches. Aber nur um $prefix oder LDFLAGS zu ändern?
Ist mir auch schon passiert, keine Bange. Aber ich wüsste dazu auch keine andere Lösung als eben die Spec-Datei mit allen Patches dazu zu schreiben, worin man die Änderungen zentral festhalten und ausführen kann. Wenn mal z.B. im openSUSE 10.3 beim Bau meckert, dann wird kurzen Prozess gemacht und eine Weiche in die Spec-Datei eingebaut, weil ggfs. die restlichen Libraries zu alt sind, um diese anders zu linken oder bestimmte Funktionen auszuschalten.
Aber dann guck dir mal cmake, bjam, IIRC smake, ... an. Da sind irgendwelche Flags für den Compiler hart verdrahtet, oder im besten Fall in irgendwelchen *systemweit gültigen* Files hinterlegt und nicht per Kommandozeile änderbar, die aufgrund irgendwelcher Dinge dann gesetzt werden. Und im OBS kannst du die Systemweiten nicht anpassen! Da kannst du gar nicht so viel fressen wie du kotzen willst. Wende dich an die Leute vom Upstream. Man kann gar nicht genug wiederholen. :-)
Du meinst, die boost-Leutkens würden wg. mir von bjam auf automake umsteigen?
Die Boost-Leutkens sind auch nur Menschen und haben halt ein neues Werkzeug für den Bau von Boost kreiert. Die Erfahrung machen wir nun mal alle jetzt.
Die automake / autotools / make mögen ein großer Haufen Dreck sein (so bezeichnen sie einige), aber ich als (u.a.) Paketbauer kann da weitgehend und meist _einfach_ steuern, wie eine bestimmte Datei gebaut wird, dank weitgehend standardisierter Variablen wie CFLAGS, CXXFLAGS, LDFLAGS, DESTDIR usw. Ich ziehe die autotools, trotz der Macken letztlich vor. Von automake oder autotools sollte man mit Abstand genießen. Da evtl. wichtige Flags überschrieben werden. Hier muss man 3 Mal kontrollieren, ob wirklich alles richtig gelaufen ist.
Ist immer noch viel einfacher. Und überschreiben muß man i.d.R. gar nichtmal, da es bei sauber generierten Makefiles Variablen gibt, über die man gezielt seine Flags reinbringen kann.
Und kannst du auch in automake bzw. autotools systemspezifische Schalter für bestimmte openSUSE Versionen für den Bau betätigen? Nein. Daher fällt das ganze wieder auf die Spec-Datei, um die "configure.ac"-Datei bzw. "Makefile.am" zu modifiziern und abschließend ein autoreconf auszulösen.
Und portabel ist der Kram auch noch. Ich hab mal wget unter Win95 mit den Buildtools vom Visual Studio 4 oder so gebaut. Ging. Einfach so. ./configure, nmake, nmake install (oder install per Hand, weiß nimmer). Shell war IIRC cygwin-bash. Wenn es keine große Abhängigkeiten gibt, dann haben die vom Upstream gute Arbeit geleistet, dass es wenigstens läuft. :-)
Jup. wget ist sauber.
Gut, da sind wir ja einer Meinung. :-)
Und wenn ich mir die ellenlangen Dateien von cmake / bjam in den Verzeichnissen so angucke ... Und wie ewig lang (>>10 min) bjam hier rumeiert, bevor es auch nur das erste Mal den Compiler anwirft (bei libboost), und dann auch noch scheinbar ziemlich kaputte Abhängigkeiten der Sourcen/Objects zu haben scheint ... Mit libboost kann ich auch was erzählen. Da gab es ein "hash resize" bug, der jetzt behoben wurde. Ich bin für den Paketbau von PokerTH zuständig und dieses Paket benötigt halt libboost. Das PokerTH-Team (Upstream) hat mir mitgeteilt, dass das libboost 1.39 ein Fehler hat.
Oha. PokerTH. Verwende ich...
Verwenden oder spielen. ;-) Na, dann: Have a lot of fun. Aber nur eines Vorweg. Damals als ich PokerTH 0.6.3 im OBS bauen ließ, hatte mein Vorgänger die libboost 1.36 statisch gelinkt. Auf Nachfrage an das OBS-Team, ob ich die neue Boost 1.38 weiterhin statisch verlinken kann, gab es bei denen haue haue auf die Finger. So beschloß ich, die libboost zu entkoppeln und diese einfach nur gegen zu linken. Da musste ich praktisch die ganze Spec-Datei anfassen bzw. wohl eher neuschreiben, weil da einfach das Chaos ausgebrochen war, um irgendwelche Merkwürdigen Lecks mit sed und awk zu schließen. Wegen dem guten Kontakt zum Upstream benötige ich die Tools sed und awk nicht mehr. Mehr Kommunikation unter uns Paketbauern würde nicht schaden. Hierfür müssten wir eine WIKI-page für jedes Package mit sämtlichen Abhängigkeiten erstellen, um mögliche Konflikte mit *ALLEN* abzusprechen.
Wobei der Server von PokerTH abkratzen kann. Hört sich schlimm an, ist aber mit einem Patch schnell behoben. Ich habe bereits ein Fehlerpatch an das OBS-Team der Factory gesendet und habe es eingepflegt. So, und wenn noch was kaputt ist, dann wende dich an das Upstream. (Habe ich das nicht eben schon gesagt?!) In dem Fall war es beim Upstream der Fehler bekannt und ein Patch stand zu Verfügung.
libboost ist IMO v.a. nervig. Nervig zu kompilieren (klappt hier mit keiner bisher probierten 1.3x Version, weder mit gcc-2.93.3, noch 3.3.5), nervig den von diversen Programmen (angeblich) geforderten Versionen hinterherzuhecheln ...
AFAIK fluchen auch die Packager der Versionen der OpenSUSE Releases gerne mal über libboost ...
Ja, jüngsten habe ich mitbekommen, dass es ziemliche Probleme mit Boost und OpenOffice gab. Auch wegen dem "hash resize". *roll_eyes* Mittlerweile habe ich auf gut Zureden das Upstream-Team überzeugen können, noch nicht auf Boost 1.39 und qt 4.5.2 umzusteigen, weil es eben zu wenig erprobt ist. Um genau zu sein, wäre es für openSUSE 11.2 echt fatal, wenn irgendwelche Anwendungen wegen fehlerhaften Libraries abstürzen.
... ist mir ein simples Makefile.am dann doch lieber. Und die Makefile.in / Makefile haben eine wohldefinierte Struktur, die sich aus den Makefile.am ergibt, d.h. auch als Paketbauer reicht es meist nur ins .am zu gucken. Das wahrlich die einfachste Lösung, wenn der Upstream halt sauber gearbeitet hat.
Bei autotools/automake kann man das recht einfach auch noch per Kommandozeile oder patch (von configure, aclocal.m4, ...) _zentral_ aber lokal, auch im OBS, reparieren, da es eine build-lokale Datei betrifft. Aber wie willst du (als non-root-build) sauber in /usr/{lib,share}/irknwas was patchen?
Was willst du eigentlich im Nachhinein in /usr/{lib,lib64} rumfummeln? Leuchtet mir nicht ein, sorry. Eigentlich patcht man vorher in den Quellen. Und nicht wenn es fertig ist!!! Hm... Gruß Sebastian -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mon, 17 Aug 2009 04:13:23 +0200, you wrote:
Und kannst du auch in automake bzw. autotools systemspezifische Schalter für bestimmte openSUSE Versionen für den Bau betätigen? Nein.
Doch, kann ich, wenn ich entsprechende Tests für Autoconf schreibe, dann kann ich sehr wohl sowas realisieren. Das Probelem bei Boost-Jam ist, dass Du dich mit einem komplett andeen Buildsystem bescghäftigen musst, dass (zumindest innerhalb der Distribution) nur von Boost verwendet wird.
Hierfür müssten wir eine WIKI-page für jedes Package mit sämtlichen Abhängigkeiten erstellen, um mögliche Konflikte mit *ALLEN* abzusprechen.
Stoss doch mal die Diskussion auf opensuse-packagers an. Du dürftest bei den meisten Packagern offene Türen einrennen.
Um genau zu sein, wäre es für openSUSE 11.2 echt fatal, wenn irgendwelche Anwendungen wegen fehlerhaften Libraries abstürzen.
Fehler in den Libraries sind nie zu vermeiden und in der Vergangenheit hat es in der Hinsicht mit Boost in openSUSE relativ wenig Probleme gegeben. Das kann aber auch daran liegen, dass boost relativ selten von Paketen in der Distribution verwendet wird und wenn dann eben nur kleine Teilbereiche. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo Philipp, Philipp Thomas schrieb:
On Mon, 17 Aug 2009 04:13:23 +0200, you wrote:
Und kannst du auch in automake bzw. autotools systemspezifische Schalter für bestimmte openSUSE Versionen für den Bau betätigen? Nein.
Doch, kann ich, wenn ich entsprechende Tests für Autoconf schreibe, dann kann ich sehr wohl sowas realisieren.
Das Probelem bei Boost-Jam ist, dass Du dich mit einem komplett andeen Buildsystem bescghäftigen musst, dass (zumindest innerhalb der Distribution) nur von Boost verwendet wird.
Okay, hört sich zwar an, dass man sich da intensiv reinlesen muss. Es ist zwar ärgerlich bei neuen Sachen. Aber letzendlich kann ich da auch nichts machen, weil es vom Upstream so gewünscht ist.
Hierfür müssten wir eine WIKI-page für jedes Package mit sämtlichen Abhängigkeiten erstellen, um mögliche Konflikte mit *ALLEN* abzusprechen.
Stoss doch mal die Diskussion auf opensuse-packagers an. Du dürftest bei den meisten Packagern offene Türen einrennen.
Die Diskussion habe ich auf der Mailingliste
Um genau zu sein, wäre es für openSUSE 11.2 echt fatal, wenn irgendwelche Anwendungen wegen fehlerhaften Libraries abstürzen.
Fehler in den Libraries sind nie zu vermeiden und in der Vergangenheit hat es in der Hinsicht mit Boost in openSUSE relativ wenig Probleme gegeben. Das kann aber auch daran liegen, dass boost relativ selten von Paketen in der Distribution verwendet wird und wenn dann eben nur kleine Teilbereiche.
Um auch auf den Vorschlag von vorhin mit den Wiki-pages zurück zu kommen. Es geht aber nicht nur um Boost, sondern auch um andere Pakete, die voneinander abhängig sind. Jetzt stell dir mal folgende Situation vor, was mir schon wg. Boost passiert ist. Der Boost-Maintainer, in dem Fall du, updatest das Package auf die neue Version. Wie es auch passiert ist. Und jetzt stell dir vor, ich hätte vom Boost update nichts mitbekommen. Zuerst fällt der Fehler im PokerTH-Server nicht auf. Aber hinterher hätte man sich gewundert, warum das Ding ständig crashed. Durch dieses Informationsdefizit (Update der Boost-Package) habe ich leider Zeit verloren, weil es bis zum Fix des Boost-Package auch noch mal dauerte. Im günstigsten Fall läuft es innerhalb 1-3 Tagen wieder. Im schlechtesten Fall würde das neue Boost-Paket nur Probleme mit sich bringen und die Anwendungen, die darauf aufbauen, laufen für die Zeit nicht mehr und zudem habe ich auch keine Möglichkeit, dass alte Boost-Package vom OBS zu installieren, weil es vom Build Server nach erfoglreichem Bau gelöscht wird. Normalerweise müsste ich für die Zukunft die automatischen Boost-Updates abstellen, um die PokerTH-Spieler nicht mit einer neuen fehlerhaften Boost zu ärgern (Zeitgleich müsste ich das Package PokerTH unter dem Repo games auf unbestimmte Zeit offline stellen und direkt auf mein Repo home:Freespacer:pokerth mit der alten Boost bauen. Im Moment ist dort Boost verlinkt und von PokerTH eine SVN-Version zum Testen) Letzendlich fällt der Frust dann auf mich und so leid es mir auch tut würden wir beide wegen dem Update in die Wolle bekommen. Das möchte ich gerne mit meinem Vorschlag vermeiden, weil man es im Vorfeld die Sache lokal auf meinem Rechner testen kann und bei Problemen kann man sich mit dem Upstream, Deps Packager, usw. zusammen setzen. Angenommen Boost wäre sehr weit in der Distribution verzahnt, hätte es in einer echten Katastrophe enden können, weil die wenigen es nicht getestet haben (Zeit) oder konnten (fehlerhafter Bau). Fehler werden erst nach dem Bau des abhängigen Package entdeckt, dann aber ist der Schaden schon angerichtet und man verliert wertvolle Zeit und vielleicht auch das Image von OBS bzw. openSUSE. Gruß Sebastian -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Tue, 18 Aug 2009 08:50:55 +0200, you wrote:
Durch dieses Informationsdefizit (Update der Boost-Package) habe ich leider Zeit verloren, weil es bis zum Fix des Boost-Package auch noch mal dauerte.
Es funktioniert nun mal nur asyncron. Zuerst wird, wenn keine grossen Probleme bekannt sind, die Bibliothek auf die neue Version gehievt. Dann zeigt sich, ob es bei den abhängigen Paketen zu Problemen kommt die eventuell behoben werden müssen.
weil man es im Vorfeld die Sache lokal auf meinem Rechner testen kann und bei Problemen kann man sich mit dem Upstream, Deps Packager, usw. zusammen setzen.
Das funktioniert in der Realität nicht. Du wirst niemals alle unter einen Hut bekommen und ausserdem gilt es, bestimmte Deadlines einzuhalten, weil Dir als Packager sonst für 18 Monate die Hände gebunden sind.
Fehler werden erst nach dem Bau des abhängigen Package entdeckt,
Natürlich entdeckst Du die meisten Probleme erst nach dem Bau, das liegt in der Natur der Sache.
dann aber ist der Schaden schon angerichtet und man verliert wertvolle Zeit und vielleicht auch das Image von OBS bzw. openSUSE.
Definitiv nein! Der Update geschieht in Factory, da sollte *jedem* klar sein, dass es eine permanente Baustelle ist, wo immer mal etwas nicht funktionieren kann. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mon, 17 Aug 2009, Sebastian Siebert schrieb:
David Haller schrieb: [..]
Eben. Vom Upstream kommt viel, das "Schweinkram" erforderlich macht. In jeder neuen Version wieder (anders).
Aber das OBS verhindert (praktisch), daß man sowas einfach mal systemweit flicken kann, sondern das jedesmal im Spec machen muß.
Systemweit geht es aber nicht so einfach.
Eben.
Sonst würden wir ja nur ein floating OS haben, dass ineinander fließt.
Es geht um Konfigurationsdateien wie die von aclocal -- oder eben konkret um die von bjam. [..]
Ich hab nix gegen patches. Aber nur um $prefix oder LDFLAGS zu ändern?
Ist mir auch schon passiert, keine Bange. Aber ich wüsste dazu auch keine andere Lösung als eben die Spec-Datei mit allen Patches dazu zu schreiben, worin man die Änderungen zentral festhalten und ausführen kann. Wenn mal z.B. im openSUSE 10.3 beim Bau meckert, dann wird kurzen Prozess gemacht und eine Weiche in die Spec-Datei eingebaut, weil ggfs. die restlichen Libraries zu alt sind, um diese anders zu linken oder bestimmte Funktionen auszuschalten.
Eben. [..]
Und kannst du auch in automake bzw. autotools systemspezifische Schalter für bestimmte openSUSE Versionen für den Bau betätigen? Nein. Daher fällt das ganze wieder auf die Spec-Datei, um die "configure.ac"-Datei bzw. "Makefile.am" zu modifiziern und abschließend ein autoreconf auszulösen.
Das ist aber eher selten nötig -- im Normalfalls kannst du alles relevante per ./configure-Parameter oder make-VARIABLE auf der Kommandozeile / in der Umgebung übergeben, d.h. bequem von .spec aus, ohne files zu patchen. Was natürlich auch ginge. Bei bjam, cmake hab ich's jedenfalls aufgegeben. [..]
Oha. PokerTH. Verwende ich...
Verwenden oder spielen. ;-) Na, dann: Have a lot of fun.
Spielen :) Danke ;) [..]
Hierfür müssten wir eine WIKI-page für jedes Package mit sämtlichen Abhängigkeiten erstellen, um mögliche Konflikte mit *ALLEN* abzusprechen.
Gute Idee ;)
Bei autotools/automake kann man das recht einfach auch noch per Kommandozeile oder patch (von configure, aclocal.m4, ...) _zentral_ aber lokal, auch im OBS, reparieren, da es eine build-lokale Datei betrifft. Aber wie willst du (als non-root-build) sauber in /usr/{lib,share}/irknwas was patchen?
Was willst du eigentlich im Nachhinein in /usr/{lib,lib64} rumfummeln? Leuchtet mir nicht ein, sorry. Eigentlich patcht man vorher in den Quellen. Und nicht wenn es fertig ist!!! Hm...
Diverse Software hat dort Templates / Konfigurationsdateien. Z.B. tmake und qmake. Versuche z.B. mal 'qmake' ein '-Wl,-t' oder '-Wl,-rpath,/opt/irgendwas' in die QMAKE_LFLAGS zu mogeln _ohne_ die *.pri, *.pro des Projektes zu patchen ... Installiere dir z.B. QT<next> nach /opt, oder ne andere Version von gcc ... Und versuch dann dagegen Qt-Kram zu bauen. Da will man eigentlich die qmake-Vorlagen (.conf) anpassen, damit man nicht immer die .pro ändern muß. Hab ich hier lokal auch schon öfter gemacht. Und das geht im OBS prinzipbedingt nicht. Da kommt Freude auf. -dnh -- "...you want a .sig with that?" -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (3)
-
David Haller
-
Philipp Thomas
-
Sebastian Siebert