Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
<snip>
> > 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.
>
> Das wuerde bedeuten alle Maintainer muessen QM betreiben...
Nein, nicht alle. Ein paar reichen schon aus. Die anderen profitieren
davon ja auch. BTW würde sich der Gesamtaufwand auch reduzieren,
weil nicht mehr so viel gefummelt werden muß.
<snip>
> Das klappt eventuell noch bei den freien Distro's wenn du wirklich ein
> Distro-uebergreifendes QM-Projekt schaffst (weil dann wieder genug Leute
> da sind die sich ums QM kuemmern koennen). Wie das aber bei den
> kommerziellen aussieht kann ich ueberhaupt nicht einschaetzen.
Ehrlichgesagt: die kommerziellen interessieren mich wenig.
Ich leiste nicht gemeinnützige Arbeit, damit andere damit Geld machen
können. Besonders von den kommerziellen erwarte ich, daß sie sich
intensiv in dem QM-Projekt engagieren.
<snip>
> > 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.
>
> Zumindestens in Debian ist es so, wenn festgestellt wird (meist durch
> den DM) dass ein Debian-Bugreport eigentlich ein Upstream-Problem ist
> und Upstream sich als kooperativ erwiesen hat macht er ein
> followup-to-upstream oder bittet (wegen z.B. Nicht-Reproduzierbarkeit)
> den bug-reportenden User Upstream einen Bugreport einzureichen.
>
> Oftmals klappt das, aber AFAIK manchmal auch nicht. Es duerfte durchaus
> eine Reihe von Bugreports geben wo sich der Reporter nach der initialen
> Mail nicht mehr meldet...
Ich rede hier erstmal von Problemen, die bereits beim Build oder den
Constraint-Tests auftreten. Die sollte der Paket-Maintainer ja direkt
mitbekommen ...
<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.
>
> Ich nicht (aka, ich hab noch keine Zeit fuer LFS auf x Architekturen
> gehabt). Ich "hoere" aber immer mal wieder das alles abseits von i386,
> PPC und ia64/amd64 richtige Probleme machen kann...
Allein schon crosscompile + sysroot ist zT. ein Krampf.
Ich habe da schon dutzende Pakete flicken müssen.
<snip>
> > 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.
>
> Debian-Pakete haben dafuer einen recht guten Mechanismus, die Patches
> werden innerhalb des Debian-Source-Pakets gehalten (dazu gehoert der
> upstream-source, eine Beschreibungsdatei und ein diff.gz mit den
> diversen Debian-spezifischen Aenderungen).
Ja, diese Trennung ist auch sinnvoll.
Ich pflege bei mir nur die Patches - mein Distro-Builder zieht die
upstream-sources automatisch ran (wenn sie noch nicht im cache liegen).
<snip>
> > 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.
>
> Dann solltest du mal ein entsprechenden Proposal auf die
> Distro-devel-Listen setzen und schauen wie die Resonanz ist.
Magst Du mir bei der Formulierung helfen ?
Hast ja immerhin schon einige gute Ideen gebracht :)
(Gilt natürlich auch für die anderen die sich an diesem Thread
beteiligt haben)
<snip>
> > Der Aufwand für die Pflege mehrere Branchen sollte sich in engen
> > Grenzen halten, wenn man die Pakete nicht so groß macht.
>
> Ich hab mich mit CVS nicht allzulange beschaeftigt aber IIRC ist das
> branchen dort nicht unbedingt einfach/guenstig...
Ich meinte das prinzipiell: Notfalls ein eigenes Projekt abspalten.
<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.
>
> Nunja, das ist ja wieder eine Sache die die Installationsprozedur
> vorschreibt... Existierende Applikationen/Libs die sich ordentlich nach
> <irgendeinpfad>/<beliebigerName> installieren lassen und dort drunter
> die benoetigte Verzeichnisstruktur erstellen sind relativ leicht
> parallel installierbar. Das groesste Problem dann ist aufzupassen (aber
> das macht ja dann das Buildsystem) dass die darauf aufbauende
> Applikation nicht die falsche Version nimmt.
Richtig. Das ist alles Sache des Build-/Installations-Systems.
Wenn man dem die richtigen Infos (in der richtigen Modellierung) gibt,
braucht man sich als Entwickler um solche Details garnicht mehr
kümmern - und soll man auch nicht.
<snip>
> Allerdings gibts auch teilweise Probleme, z.B. bei Python Packages.
Mit python kenn ich mich nicht aus. Wo genau gibt es Probleme ?
<snip>
> Wenn die nicht ueber distutils/ez-setup sondern mit anderen Methoden
> (z.B. PyQt nutzt selbstgeschriebenes configure.py und daraus generierte
> Makefiles) installiert werden wird eine Parallelinstallation von
> verschiedenen Versionen erschwert.
Aha, also wieder ein Mangel an einem ordentlichen Buildsystem nebst
sauberer Modellierung, bzw. desssen konsequentem Einsatz ?
<snip>
> > Grade bei KDE verstehe ich nicht, warum man sich immer gezwungen
> > sieht, solche "großen Würfe" machen zu wollen.
>
> Weil eben nur eine begrenzte Anzahl Entwickler da sind und diese
> schaffen es nicht frueher. Uebrigens soll die KDELibs API bis Ende des
Wäre doch grade ein kontra-Argument ;-)
Mir ist zB. nicht ganz klar, warum KDELibs ein Paket und nicht mindestens
zehn verschiedene ist.
Ein Paket für eine Aufgabe. Ist das nicht grad die Unix-Philosophie ? ;-)
<snip>
> > Man hat manchmal ein Eindruck, daß es sich um ein riesiges
> > Mammut-Projekt, anstatt vieler einzelner handelt.
>
> Das ist ja in gewisser Weise auch richtig, weil zu einem KDE-Release
> eben ein komplettes DE geliefert werden soll.
Von solchen Ansprüchen sollte man sich verabschieden, wenn man nicht
genau in die Windows-Falle laufen will ...
<snip>
> > Ü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.
>
> Auch kdelibs besteht aus mehreren Teilen. Allerdings lassen die sich
> nicht einzeln, losgeloest von KDE benutzen. Jedenfalls nicht in KDE3.
> Fuer KDE4 ist aber geplant eine strengere Trennung in "Core", "Ui" usw.
> vorzunehmen, so dass KDE-Technologie auch ausserhalb reiner
> KDE-Anwendungen genutzt werden kann (z.B. KIO).
Na da bin ich mal hochgespannt. Große Erwartungen hab ich da
allerdings nicht.
<snip>
> > 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 ...
>
> Das gilt IMHO im DE-Bereich allgemein. Man will nunmal das ultimative DE
> fuer alle herstellen. Ja das ist ein Streben nach Windows-Aehnlichkeit
> und nein ich finde das nicht immer gut.
IMHO eine Sache die man besser bleiben lassen sollte. Diesen Anspruch
kann man ohnehin nicht erfüllen, es sei denn, die Maschinen lernen
denken und die Menschen hören völlig damit auf.
<snip>
> > > 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 ?
>
> Jupp. Ich hab ja Softwaretechnik gehoert *bruest* ;-) Im Ernst mir ist
> prinzipiell schon klar was du meinst. Ich denke ein Problem duerfte
> sein, dass dies nicht fuer alle (alteingesessenen) Entwickler gilt. Und
> der Mensch ist von Natur aus traege, er lernt keine neuen Kunststuecke
> mehr (oder nur sehr ungern).
Auf die Faulheit anderer nehm ich aber keine Rücksicht (es sei denn
vielleicht, ich werde bezahlt dafür ;-))
<snip>
> > An Deinem Beispiel Qt:
> >
> > Die Basis-Bibliothek (libqt) enthielte dann nur ein paar ganz
> > grundlegende Basis-Typen, (QObject, etc).
>
> Die heist bei Qt4 libQtCore.so enthaelt u.a. QObject, QString, den
> Meta-Object-Spass und IIRC auch die Container-Geschichten.
Genau das. Und nicht mehr.
Und schwupps kann man das weitgehend unabhängig von den anderen
Komponenten entwickeln. Wem irgentwann mal dieser Core nicht reicht
(weil er andere Typen braucht), der kann dafür eine eigene Lib
bauen und benutzen. Wenns ich das durchsetzt, wird vielleicht mal
der alte Core überflüssig, indem ihn einfach niemand mehr
benutzt. Da muß man keine großen Schnitte mehr machen, das
ergibt sich dann von ganz allein, wenns sinnvoll ist.
<snip>
> > Weder widgets noch andere
> > komplexe Typen haben hier etwas zu suchen - das kommt in eine
> > andere Library und ggf. sogar in ein separates Paket.
>
> UI ist in libQtGui, dann haben wir noch libQtXml, libQtNetwork und
> libQtSql.
ACK. Allerdings wäre da sicherlich QtGUI noch weiter zu splitten.
QtXml würde sinnvollerweise nur ein Wrapper auf eine schlankere,
bewährtere Implementation (zb. expat) darstellen. Damit wird Code
minimiert und es gibt weniger Chancen auf Bugs.
<snip>
> > Aber ganz prinzipiell halte ich für ein System wie Qt/KDE einen GC für
> > Grundvorraussetzung. Das würde die Code-Komplexität,
>
> Du meinst die Destruktoren der Klassen waeren leer?
In 99,9% der Fälle braucht man keine mehr. Allenfalls wenn externe
Resources (FD's, etc) freigegeben werden müssen, etc.
<snip>
> Eventuell noch einige Stellen an denen, Dialoge auf dem Heap erzeugt
> werden, aber noch in derselben Funktion wieder geloescht werden
> (was aber auch Bloedsinn ist, da Qt dafuer ein passendes Flag
> bereithaelt - DeleteOnClose)
Solche Automatismen sind ja schön und gut, bergen aber unnötige
Komplexität. Mit einem GC kann das alles in einem Abwasch erleidgt
werden.
<snip>
> > und damit auch die Fehlermöglichkeiten und damit verbundenen
> > Arbeitsaufwand, massiv zu reduzieren.
>
> Hmm, QObjects und alle UI-Elemente sind bereits mit GC ausgeruestet.
> Zumindestens in der einfachen Form, dass sobald das Elternobjekt
> verschwindet sie auch geloescht werden.
Sehr schlechte Idee. Vielleicht fallen Dir die Gründe selbst ein.
<snip>
> So ein Monster ist KDE im Speicher glaube ich gar nicht (mehr),
> OOo und X11 selbst druecken (hier jedenfalls) viel eher.
Über OOo will ich mich garnicht erst auslassen ...
X11 ist dank der Modularisierung auf einem guten Weg der Gesundung,
ich trage da auch meinen kleinen Teil dazu bei :)
<snip>
> > 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.
>
> Was ich von GC immer hoere ist, dass es die Programme langsamer macht.
"Geh nicht in den dunklen Wald, denn dort erwarten Dich schlimme Dinge" ...
Man muß nicht jeden Unsinn glauben, der irgentwo verbreitet wird,
besonders wenn er irgentwelchen Voruteilen oder religiösen Ansichten
entspringt ...
<snip>
> > > > 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
>
> Ich denke 10 Jahre, Qt3 ist aber IIRC nur etwa 3 oder 4 Jahre alt. Qt2
> kenn ich nicht. Und es wird auch erwartet dass Qt3 noch eine Weile
> weiter besteht, da die Portierung zu Qt4 beinahe einem Rewrite der
> Applikation (jedenfalls bei was komplexerem als Hello World)
> gleichkommt.
Ohah, 10 Jahre. Aber noch immer kein GC.
Vielleicht ja in den nächsten 10 Jahren ? ;-)
<snip>
> > > 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.
>
> Nunja, man kann die von Qt definierten Datentypen weiterverwenden und
> muss sich nicht mit den diversen DB-Lib-API's rumaergern.
Wieso rumärgern ?
Wo kann man denn bei einer SQL-Anbindung nennenswert von einem GUI-
Toolkit profitieren ?
<snip>
> > Okay, wenn man schon unbedingt schon ein paar Qt-Konzepte haben will
> > (zB. die Signals) in einer SQL-Library braucht (warum auch immer ...),
>
> Ich glaube weniger Signals, aber z.B. Qt Datentypen wie QString,
> QByteArray, QDate. Ich muss ansonsten die Konvertierung von char* selbst
> durchfuehren, das nimmt mir Qt an der Stelle ab.
Dafür reicht ja wohl ein kleiner Wrapper aus, der auf eine
bewährte Bibliothek setzt. Dazu muß man nicht alles neu programmieren.
<snip>
> > warum dann nicht ein separates Qt-SQL, das auf Qt aufbaut, und evtl.
> > sogar gleich vorhandenes und erprobtes (unixODBC) wiederverwendet ?
>
> s. Qt4, das gibts jetzt. ODBC-Treiber haben sie IIRC auch.
Ja, nach 10 Jahren ... ;-)
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: