Re: apt-get upgrade rückgängig machen
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
Reply to: