Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
<snip>
> > Ich denke, beide Parteien tragen Ihren Teil dazu bei.
> > Aber gerade die Distro-Maintainer sollten da etwas konsequenter
> > und radikaler in ihren QS-Anforderungen sein.
>
> Genau, damit keiner mehr die Distro benutzt/kauft, da das alle
> Distro-Maintainer machen, kauft/benutzt niemand mehr Linux. Ist ja
> nicht so schlimm, Alternativen existieren ja.
Nein, damit sich die Qualität erhöht, und mehr Menschen die
Distro mit geringerem Aufwand für eigene Anpassungen nutzen können.
Harte QM-Anforderungen bedeuten nicht zwangsläufig, daß diese
von weniger Paketen erfüllt werden, sondern allenfalls daß es etwas
länger dauert - für eine stabile Distro nicht unbedingt so schlimm.
Man könnte auch andersrum argumentieren: durch die hohen Anforderungen
(und damit verbundenen regelmäßigen Prüfungen) werden derartige
prinzipielle Fehler schneller (noch vor der Aufnahme in die Distro)
erkannt und vermutlich auch schneller korrigiert. Ich gehe mal davon
aus, daß der Paket-Maintainer dem Entwickler-Team gleich mitteilt,
wenn er einen Fehler findet, und vielleicht ist er ja selbst im Team
und kümmert sich gleich drum.
<snip>
> > + Vollautomatischer, nicht-interaktiver build.
>
> KDE kann man prinzipiell ausm svn vollautomatisch inter-aktiv bauen
> lassen. Auch bei Debian's buildd's klappt das sehr gut. Sofern eben
> keine Fehler beim Paketieren gemacht wurden, bzw. bei KDE keine Fehler
> im aktuellen Code existieren.
Ich kenne viele Pakete, zT. grundlegende Pakete, die sich nicht so
einfach bauen lassen.
Möglicherweise pflegen da einzelne Distros ihre eigenen Branchen
bzw. Patches, mit denen das geht (so wie ich das ja auch tue), aber
es scheint nicht rechtzeitig in den Mainstream zurückzufließen.
Deshalb ja auch mein Vorschlag in diesem Thread, ein Distro- und
Paket-übergreifendes QM-Projekt aufzubauen, das sich und den Paketen
hohe Meßlatten anlegt und eigene, streng getestete Branchen pflegt.
Ich denke, daß solch ein Projekt für alle Distros nützlich
sein dürfte, da diese dann nicht mehr ihre eigenen Patches pflegen
müssen. Demzufolge sollten dann auch aus den einzelnen Distros
hinreichend viele Leute mitmachen.
<snip>
> > + Libraries -> 100% abwärtskompatibel (zumindest auf Quell-Ebene)
>
> Soll ich jetzt mal ROFL schreiben? Spaetestens bei Major-Versions werden
> i.A. die Source-Interfaces geaendert. Nicht wegen schlechtem Design,
> sondern weil sich die Anforderungen/Wuensche weiterentwickelt und
> veraendert haben. Genau dafuer gibts ja Major-Versions.
Das ist aber schlecht. Stattdessen sollte es eine *neue* library geben
(aus libfoo wird libfoo2), oder mit anderen Worten: das Major-Release
steckt im Libnamen. Einige Projekte arbeiten schon lang so.
<snip>
> 100% Abwaehrtskompatibilitaet ist das was Windows bis WinME "versucht"
Eh ?
Möglicherweise haben das einige Leute dort versucht, aber im
Endergebnis ist man auf ganzer Linie gescheitert. Nach '95 hätte
man sofort auf NT umsteigen und den alten Code im Emulator/VM-Adaptor
(ähnlich WINE) laufen lassen sollen. Aber das ist ja nun nicht
unser Bier (oder ist hier jemand bei M$ beschäftigt ?) ;-)
<snip>
> > > > Wenn sich in einer Library von einer Version zur nächsten die
> > > > Interfaces inkompatibel werden, dann ist das ein Designfehler,
> > >
> > > Das kommt auf den Versionssprung an... Von 3.4.X auf 4.X.X darf sowas
> > > sein (um mal beim KDE-Beispiel zu bleiben, Zahlen sind aber beliebig
> > > austauschbar).
> >
> > Nein, auch dann nicht. Man muß ein neues Paket / eine neue Library
> > bauen, also zB. libfoo1, libfoo2, ... diese Libs müssen natürlich
> > auch problemlos koexistieren können.
>
> ?? Um sowas anzuzeigen gibts den Soname bei Libraries (im Sinne von
> nativen Linux-Libs). Bei Python loest man das ganze wohl mit sog. eggs
> oder eben neuen Namen mit der neuen Major-Revision drin.
Ja, auf einigen Plattformen gibt es das, aber nicht überall.
Außerdem besteht eine lib oft aus mehr als nur dem shared object.
Die Major-Revision nicht nur in den Libnamen, sondern generell den
Paket-Namen zu stecken, halte ich für den praktikabelsten Weg,
der ja auch von vielen Projekten beschritten wird.
> > > > unabhängig vom individuellen Gefühl der jeweiligen Autoren.
> > > > Solche Libs (-Versionen) sollte man einfach nicht benutzen, sondern
> > > > ggf. reparieren.
> > >
> > > In der Praxis gibts leider Faelle wo sich die Autoren nicht sonderlich
> > > darum kuemmern ihre ABI kompatibel zu halten und man leider keine
> > > vernuenftigen Alternativen hat.
> >
> > Dann muß man eben mal in den sauren Apfel beißen und sich selbst
> > der Sache annehmen, notfalls eine neue Branche aufmachen.
>
> Genau, ich schreib mal eben schnell ne SSL library, so in 2 Stunden
Mußt Du nicht. Du brauchst ledeglich die existierende zu reparieren.
Entsprechender Medienrummel (vorallem auf den Listen) sollte da sicher
auch behilflich sein.
Wie bereits oft gesagt: das muß ja nicht alles einer alleine machen.
Das von mir vorgeschlagene QM-Projekt sollte da eine nützliche
Hilfe darstellen. Jemand hier interessiert ?
<snip>
> > Übrigends kann ich mit ABI-Inkompatiblitäten zwischen major-Releases
> > grade so noch leben (evtl. sollte man aber eine ABI-Revision mitpflegen),
> > aber zumindest auf source-Ebene *muß* es passen - sonst ist das für
> > mich Schlamperei.
>
> So nu muss ich aber wirklich: ROFL.
>
> Wie willst du denn deine Library and neue Anforderungen anpassen? Oder
> kennst du alle jemals auftretenden Anforderungen im vorneherein? Achso
> du ueberlegst dir einfach nen neuen Namen und startest von vorne.
Nein, wenn sich das Interface wirklich ändern muß (dh. eine Erweiterung
nicht mehr ausreicht), dann knappt man eine neue Branche ab und gibt
dieser einen neuen Namen, zB. libfoo2 statt libfoo.
Der Aufwand für die Pflege mehrere Branchen sollte sich in engen
Grenzen halten, wenn man die Pakete nicht so groß macht.
In Deinem OpenSSL ließen sich auch einige Teile in eigene Projekte
auskoppeln, zB. Handling von cryptchips, random-generatoren, etc.
<snip>
> Major Releases werden genau deswegen gemacht, weil man die ABI und die
> API brechen muss um neue Dinge einfliessen zu lassen.
Soweit okay. Aber dann sollte das Paket die Major-Version im Paketnamen
haben. Vielleicht sollten wir dieser noch etwas weiter unterscheiden:
+ Allgemeiner Name (zB. "OpenSSL) -> für den User
+ Kanonischer Name (zB. "openssl")
+ Major-Revision: 1,2,3 ...
+ Voll qualifizierter Kanonischer Name (zB. openssl-1) -> für Deps.
Dabei muß aber auch sicher gestellt werden, daß verschiedene
Majors parallel existieren können.
<snip>
> > Ich habe selbst meine Erfahrungen damit machen müssen, wie schwierig
> > es ist, kleine aber wichtige Fixes in die official branches zu kriegen
> > (zB. DESTDIR-fix für expat)
> >
> > Deshalb hab ich mir angewöhnt, meine eigenen Fixes zu pflegen.
>
> Hmm, ist das nicht auch unguenstig? Ich meine dann muessen die Nutzer
> deiner App immer deine expat-Version benutzen. Und der Support fuer die
> die das nicht "kapieren" oder sowas wie README's und aehnliches nicht
> lesen duerfte einiges an Zeit kosten.
Als Sysop macht mir das wenig aus, weil bestimme, welche Software
aus meinen Systemen läuft. Der Nutzer nutzt bloss ;-)
Außerdem sehe ich zu, daß ich keine Interfaces ändere - ich
kümmere mich vorrangig um einen sauberen Buildprozess, womit wir
wieder am Ausgangsthema wären ...
<snip>
> > > > Wenn die Namen mir jetzt noch was sagen würden ...
> > >
> > > fam == file alteration monitor
> > >
> > > Leider total buggy und nicht mehr gepflegt.
> >
> > Wenn Du es benutzt, warum pflegst Du es nicht ?
>
> 1. Ich bin noch immer Student und hab leider andere Dinge zu tun
Haben wir alle ;-)
<snip>
> 2. Ich brauche fam nicht
Damit erübrigt sich alles weitere, weshalb ich ja auch nicht
ganz unsonst jene Einschränkung in meiner Frage gemacht habe ;)
<snip>
> > Evtl. sollte man bei gewissen Libs über kürzere Release-Zeiträume
> > nachdenken
>
> Oh, hast du ne Klon-Maschine um gute Entwickler zu klonen und allen
> Projekten so mit unendlich viel Manpower dabei zu helfen?
Nein, eben nicht. Genau deshalb will ich ja durch saubes Projektmanagement
den Arbeitsaufwand reduzieren bzw. durch Maschienen erledigen lassen.
<snip>
> Ich weiss nicht wie das bei anderen Projekten aussieht und entschuldige b
> itte dass ich immer auf das von dir so verhasste KDE zurueckkomme. KDE hat
> beschlossen nur noch Bugfix-Releases von KDE3 zu veroeffentlichen damit
> moeglichst viel Manpower in KDE4 fliessen kann, dennoch ist der aktuell
> anvisierte Release in 1.5-2 Jahren. Anderen OSS Projekten duerfte es
> aehnlich gehen.
Grade bei KDE verstehe ich nicht, warum man sich immer gezwungen
sieht, solche "großen Würfe" machen zu wollen. Man hat manchmal
ein Eindruck, daß es sich um ein riesiges Mammut-Projekt, anstatt
vieler einzelner handelt. Und genau hier sind wir bei dem Problem
der unbeherrschbaren Komplexität. Eben einer der fundamentalen
Gründe, warum Windows so schlecht ist.
Übrigends einer der wesentlichen Gründe, warum ich nichts
von KDE halte. Bei GNOME scheint mir das bei weitem nicht so schlimm,
obwohl einige Paketen (zB. glib+gtk) auch schon viel zu überzüchtet
sind.
Mir scheint, es liegt dem ein Streben nach einer superlativen
eierlegenden Wollmilchsau zugrunde. Evtl. resultiert dieses wiederum
aus dem Großgruppen inherenten Drang zur Gleichschaltung ...
<snip>
> > und erstmal eine Sache zuende bringen, bevor man eine andere anfängt.
> > Manchmal sollte man auch kleinere Brötchen backen und Libs
> > aufsplitten.
>
> Aufsplitten loest das Manpower Problem auch nicht.
Vereinfachung und Verschlankung hilft immer.
Gilt übrigends auch für politische Strukturen, falls sich
jemand hier dafür interessieren sollte ...
<snip>
> > > Auch bei OSS gibts sowas, klaro ist da eher "Es ist fertig wenn es
> > > fertig ist" das Motto. Dennoch denke ich werden vielfach Libraries und
> > > Anwendungen mit CVS-Versionen von Bibliotheken entwickelt um moeglichst
> > > frueh die neuen Features testen zu koennen...
> >
> > Das ist aber wieder Pfusch. Nicht die Anwendungsentwickelr sind zum
> > Testen einer Lib da, sondern das QM-Team der Lib.
>
> Also hast du doch ne Klon-Maschine zumindest fuers QM.
Nein, aber ich habe einige grundlegende Methodiken und Prinzipien.
Sagt Dir "design by contract" etwas ?
Erst definiert man, was ein bestimmtes Modul eigentlich leisten soll,
dann die Schnittstellen und erst dann kommt die Implementierung.
So kann man auch sehr große Projekte wunderbar clustern.
Sagt Dir (strikte) "Modularisierung" etwas ?
Man gliedert einzelne, abkoppelbare / autonome Funktionalitäten
in einzelne Module.
Beispiel: GUI-Toolkit:
Das Grund-Modul enthält nur die fundamentalsten Strukturen und Typen.
Einzelne Widgets werden in separate Module ausgelagert. Evtl. können
stark verwandte Module (zB. verschiedene Grund-Widgets) in eine
Library (-> shared object) gruppiert werden.
An Deinem Beispiel Qt:
Die Basis-Bibliothek (libqt) enthielte dann nur ein paar ganz
grundlegende Basis-Typen, (QObject, etc). Weder widgets noch andere
komplexe Typen haben hier etwas zu suchen - das kommt in eine
andere Library und ggf. sogar in ein separates Paket.
<snip>
> > > > Qt halte ich für den klassischen Kommerz-Pfusch. Überladene,
> > > > überzüchtete eierlegende Wollmilchsau, die nichtmal ein paar
> > > > Grundlegende moderne Konzepte wie garbage collection brauchbar
> > > > verwendet.
> > >
> > > GC? Bei C++? Der war gut. Da musste schon selbst GCen.
> >
> > boehm-gc ?
>
> Naja, modern find ich den ja nicht ;-) (Nein ich kenne ihn nicht, nur
> anhand der Paper-Daten).
Warum nicht ? Weil er älter als 1 Jahr ist ? ;-)
BTW: wenn jemand einen besseren Vorschlag machen möchte, bin ich
dafür jederzeit offen. Aber ganz prinzipiell halte ich für ein
System wie Qt/KDE einen GC für Grundvorraussetzung. Das würde
die Code-Komplexität, und damit auch die Fehlermöglichkeiten
und damit verbundenen Arbeitsaufwand, massiv zu reduzieren.
<snip>
> Ansonsten ziehe ich mich jetzt lieber aus dem Thema zurueck, denn
> mit MM hab ich bisher nicht sooo viel am Hut gehabt
> (ausser aufzupassen meine Objekte nicht zu frueh zu deleten).
> Achja: Ich habs auch lieber mich nicht drum kuemmern zu muessen,
> das geb ich schon zu.
Genau hier haben wir ja ein massives Problem in gängiger SWE:
Es wird viel Zeit damit vergeudet, irgentwelche memleaks zu finden,
die bei sauberer Strukturierung (und dazu gehört ab einer gewissen
Graphenkomplexität auch ein GC) grundlegend vermieden würden.
Ich kenne jetzt keine wirklich brauchbaren Statistiken, aber aus
eigenen Projekten weiß ich, wieviel Zeit ich durch (zT. natürlich
auch selbst verschuldeter) unsauberer Strukturen im Debugging
verbrennen mußte. Jetzt im Nachhinen weiß ich, daß es zT.
besser gewesen wäre, das eine oder andere Projekt neu zu programmieren.
<snip>
> > Eines der wesentlichen Konzeptionsfehler von Qt ist, daß es zu
> > viel auf einmal will.
> >
> > BTW: kann man mittlerweile auch eine Qt-Anwendung ohne grafisches
> > Display (Xserver, etc) starten ?
>
> Ja, mit Qt4.
Oh, da hat man ja sehr schnell reagiert - wie viele Jahre gibts
Qt nun schon ? ;-o
<snip>
> > Mein letzter Versuch bei qt3
> > schlug da fehl.
>
> Korrekt. qt3 braucht eine Gui. AFAIK startete Qt ja wohl auch als
> GUI-Framework und hat zumindestens bis Qt3 sein Hauptaugenmerk darauf.
Richtig. Aber man hat unentwegt immer mehr Funktionalität eingebaut,
die dort nicht reingehört. Schon mit Qt2 hätte man einen großen
Schnitt machen sollen. Bei gtk hat das auch lang gedauert, aber man
hat deutlich eher reagiert (wenngleich ich auch der Meinung bin,
daß es nicht hinreichend konsequent getan wurde)
> Dinge wie SQL-DB-Anbindung, XML und Netzwerk-Connectivity sollten dem
> Anwendungsentwickler einfach nur die Arbeit erleichtern, bzw. dafuer
> sorgen dass er nicht noch 4 andere Libs und deren Strukturen verstehen
> muss.
Eierlegende Wollmilchsau. Man baut eine 5te Struktur, damit man die
vier existierende nicht verstehen muß ... irgentwie widersinnig.
Okay, wenn man schon unbedingt schon ein paar Qt-Konzepte haben will
(zB. die Signals) in einer SQL-Library braucht (warum auch immer ...),
warum dann nicht ein separates Qt-SQL, das auf Qt aufbaut, und evtl.
sogar gleich vorhandenes und erprobtes (unixODBC) wiederverwendet ?
Hier sehe ich ein klassisches Beispiel für sinnlos verbrannte
Resourcen. Ich warte nur darauf, daß Qt seine eigene libc mitbringt.
<snip>
> > Deshalb mußte ich bei einer Anwendung, die ich
> > eigentlich nur GUI-frei machen wollte, sämtliche Qt-Abhängigkeiten
> > entfernen. Sowas war ich eigentlich nur aus der Teletubbi-Welt
> > gewohnt ... aber der Kommerz-Stumpfsinn hat eben schon längst
> > auch in der OSS-Welt einzug gehalten :(
>
> Wenn ich zu Qt3 Zeiten eine Applikation ohne GUI haben haette wollen
> haette ich sowieso auf Qt verzichtet, von vorneherein. Soo umwerfend
> sind die restlichen Spaesse in der Lib naemlich auch nicht. Da kann man
> ruhig ueber ne Alternative nachdenken.
Das Problem im konkreten Fall war, daß ich eine fertige Qt-Anwendung
von ihrem GUI-Kram befreien und zu einem automatisierbaren
Kommandozeilen-Tool umbauen wollte (es handelte sich um ein SSTV-Tool,
das ich zur automatisierter Bildübertragung, für eine Art
Funk-Webcam benutzen wollte)
<snip>
> > Psychische Defizite der breiten Masse dürften wohl die Hauptursache
> > darstellen ...
>
> ACK. Das merkt man auch immer mal wieder in dieser ML, Lernresistenz und
> Faulheit kriegt man halt nicht so leicht weg. Duerfte aber auch nicht
> nur durch Software gepraegt werden, auch durch alle andalle anderen
> Lebensbereiche.
Leider. Als aktiver Politiker muß ich das leider auch immerwieder
erleben. Aber manchmal gibt es auch ein paar Lichtblicke, zB. durfte
ich heute erfahren, daß hier eine aktuelle Spendensammlung einiger
unserer lokalen Umwelt-Aktivisten (sie wollen ein paar Bäume sanieren
und neue pflanzen) einigermaßen gut anläuft. (Die Stadt hat ja
für sowas kein Geld, weil alles von der Verwaltungsmaschinerie
gefressen wird)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Reply to: