[Eisfair] update: All, but no kernel

[D. Oezbilen]

Hallo Daniel,

grossen Dank fuer deine ausfuehrliche Erklaerung.

Ich dachte mir, dass der Hund irgendwo begraben liegt, doch ich hatte 
auch 2515 + ca. 200 MB an Updates auf eine produktive Maschine 
einzuspielen. Und im Nachgang zu schauen, was net funkt. ;-)

Du hast erklaert, was/wie es funkt, Olaf zeigte auch parallel zu meinen 
Versuchen, wie die Schalter gesetzt werden muessen, Holger hat das Paket 
auch identifiziert, was den neuen Kernel bedingte.

Einzig, gestern stand ich da, egal, was ich anging, der Kernel wurde 
mitgeliefert. Habe die Flucht nach vorn angetreten und es ging dann auch 
OK, fast, ausser bind9, da geht nix (keine Namensaufloesung) mehr.

> würde. Der Grund ist, dass Abhängigkeiten zwischen den Paketen immer 
> berücksichtigt werden müssen.
jo, sowas dachte ich mir, doch so schnell zu finden wie die 
Abhaegigkeiten dargestellt werden koennen, damit ich das (v. Holger 
identifizierte) Paket deinstalliere, dafuer hatte ich nicht die Zeit.

  Daher hier ein paar
> "Hintergrundinformationen":
Vielen Dank fuer den tieferen Einblick.

> vorliegen. Hier wirken die Schalter "--unstable und --exclude".
Habe ich im Skript gesehen.

> 2. Die im Schritt 1 ermittelte Paketliste wird (intern) an "eisman 
> install" übergeben, 
Meine Idee war gerade diese Datei im /tmp abzufangen, zu editieren, dann 
wieder eisman daraus zu speisen. Doch gleichzeitig ahnte ich, dass dann 
eine Abhaengigkeit nicht aufgehen koennte und mir ein anderes Problem 
holen wuerde.

> sich auf "ausgeschlossene" oder nicht "stable" Pakete beziehen, dann 
> sind diese Pakete doch wieder dabei.
OK.

> (oder beide) verbliebenen Pakete eine Abhängigkeit auf "eisfair-base" 
> definieren.
Im Detail erklaert. So sterbe ich immerhin nicht dumm. :-)

> Ich kann mir gut vorstellen, dass Dein Fall ähnlich aussieht.
Genau, xtables wie Holger auf schon postete, bedingte K5.x
Ich bin/stand im Zugzwang, 2,5GB einspielen und/oder das WE aussetzen. 
Ich entschied mich weiter zu machen. Auch mit K5.x.

Die Umstellungen des K.-Updates haben diesmal meine lilo so gelassen, 
viel uebernommen. Sonst musste ich vorher die lilo.conf umschreiben, so, 
wie es das setup gerne sehen wollte.

Dieses mal lief alles _ohne_ Reboot durch, vor Reboot habe ich den 
default EIntrag in der Lilo ergaenzt (der wurde nicht uebernommen? auch 
den Hinweistext nicht, nicht schlimm) und konnte weiterhin den vorab 
installierten K49216 wieder booten.

> auch mal den Schalter "--listonly" ausprobierst.
Ich habe die Listen parallel gespeichert, doch so adhoc erschloss sich 
mir nicht, dass xtables der Taeter war.
So haette ich xtables deinstalliert um den proof-of-concept in der Nacht 
zu validieren.

Leider tue ich mir mit eisman etwas schwer, doch x1000 Pakete manuell 
nachziehen, noe. No risk, no fun. :-) :-) :-)

Ich weiss leider nicht, wie ich die Abhaengigkeiten der Pakete 
untereinander (ASCIII Graphik?) ueberhaupt darstellen kann, die Liste, 
die das Menue irgendwann auch liefert, was/was bedingt und automatisch 
nachzieht.

Ich selbst wuerde mehr mit eisman (dann vorgefertigte Skripte fuer 
bestimmte Pakete) statt im manuellen Menue zu arbeiten, doch die 
Einarbeitung haette dann auch fruieher erfolgen muessen. dg.

Am Ende ist _fast_ alles gut, ausser bind9, da geht im Moment keine 
Namesaufloesung mehr.
Baustelle.

Danke Dir.
Derya