Hallo Andreas, > > 2) die Abh�ngigkeiten genauer definiert werden > > Was heisst die Abh�ngigkeiten genauer definieren? Im Normalfall > sollten die Abh�ngigkeiten so weit wie m�glich und so eng wie n�tig > definiert werden. Nimm mal an jedes Paket h�tte ein Depends > libc6=2.3.X, dann m�ssten tausende Pakete neu kompiliert werden, wenn > ein neues Bugfixrelease eingespielt wird. Keine sehr gute Idee.
schon klar. Das Problem liegt aber nicht bei einem Gesamtrelease mit einer konsistenten Dependency-Landschaft, sondern wenn man die "dpkg --force-all"-Variante irgendwann mal verwendet hat. Deshalb hab ich ja auch geschrieben, da� ein Release-Definitions-Tool hier ziemlich strikt sein sollte. Denn ein Downgrade wird nur dann sauber funktionieren k�nnen, wenn der Upgrade ordnungsgem�� gelaufen ist. Ansonsten begibt man sich IMHO auf gef�hrliches Terrain. > > 3) ein downgrade-not-possible Flag definiert wird (oder aus den > > Abh�ngigkeiten erkannt wird), denn downgrade wird nicht immer m�glich > > sein. > > Dass w�rde vorraussetzen, dass jemand den Aufwand betreibt und das > downgrade testet... Wobei wir wieder bei der Manpower sind, die nunmal > begrenzt ist... ich meine, das sollte nicht n�tig sein. > Klaro, deswegen macht man ja auch kein t�gliches Upgrade auf > Produktionsmaschinen - da w�rde ich immer ein Testsystem vorhalten und > wenn dort nach X Tagen keine Fehler auftreten auf dem > Produktionssystem das Update machen... Ja ich bin mir klar dar�ber, > dass nicht jeder das Geld hat um 2 identische Maschinen vorzuhalten. > Andersrum macht man bei Produktionssystem jawohl eh nicht jedes > beliebige Upgrade mit.... Die Philosophie im professionellen IT-Management nach ITIL ist in etwa, da� man Softwarekonstellationen zentral testet und dann ein Gesamt-Release zusammenstellt, bei dem man mit geringstm�glichem Crash-Risiko die Freigabe verantworten kann. Und wenn doch was schiefgeht, sollte man mit einem definierbaren Aufwand auch bei hochskalierten Szenarien (beispielsweise die 14000 Linux-Kisten der Stadtverwaltung M�nchen) zum vorherigen Softwarestand zur�ckkehren k�nnen... Schon aus diesem Grund kann man es sich nicht leisten, auf jedem Rechner eine unterschiedliche Softwarekonstellation zu haben. Das Entwicklungsziel darf nicht der private Desktop in einer Minimalumgebung sein, sondern wir m�ssen unser Softwaremanagement f�r derart gro�e Installationen fit machen, wenn "wir" als Linux-Community da ernsthaft rein wollen. Viele Gr��e Markus
