Re: [opensuse-programming-de] Re: boost ( War: Re: wie für 32bit übersetzen?)

Sebastian Siebert <[email protected]> Tue, 18 Aug 2009 08:50:55 +0200
Newsgroups gmane.linux.suse.programming
Message-ID <[email protected]>
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
<[email protected]> mit dem Topic "Communication problem
within packagers" angestoßen. Jeder Paketbauer ist eingeladen, an der
Diskussion teilzunehmen.

>> 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: [email protected]
For additional commands, e-mail: [email protected]