[linux-l] rpm

[Tobias Schlottke]

On Thu, 8 Apr 2004, Jan Krüger wrote:
...
> Es gibt folgende Möglichkeiten:
> -Applikation bringt Z der Version 47.11 mit Funktion Y selber mit und
> installiert es da, wo es das Basissystem nicht weiter beeinflußt.
> (/opt/Applikation)
> -Zu Applikation wird ein Paket für Z mitgeliefert das installiert
> wird, wo es das Basissystem nicht weiter beeinflußt (zb.
> /opt/Applikation/z)
> - beliebig viele weitere Möglichkeiten ....

Prinzipiell finde ich das eine gute Möglichkeit. Es
widerspricht halt nur ein bißchen dem Unix Konzept. Das
führt im Extremfall für 50 Applikationen zu 50 libc's
etc. D.h. man hat n mal (fast) gleiches nebeneinander.
Schön fände ich in dem Kontext wenn ein Paketverwaltung
unterschiedliche Modi für Pakete hätte: Modus "wichtig
und notwendig" und "nur zum spielen".

> Als viel lästiger empfinde ich das unmögliche Auflösen
> von Dependency Konflikten, bei welchen man sich dan entscheiden
> darf welche Software man nun nutzen möchte
> (oder ein Zweitsystem im system aufbauen mit einem eigenen rpm-root),
> oder das bereits von Michael erwähnte 100k Beispiel, oder wenn mit
> irgend einer Anwendung gleich zig System-Libraries geupdated werden.
> Das ist wie bei Windows, ich krieg immer Gänsehaut wenn da ein
> Installer sagt: "Updating System, please Wait"

Wenn ich an dem Punkt noch zurück kann, finde ich das
ok. Das geht bei den meisten Windows Dingern halt nich.
Und das ist schon immer ein sehrrrrrr komisches Gefühl.
Vor allem wenn's lange dauert :-)

> Ich unterscheide eben zwischen Betriebssystem(1) und zusätzlicher
> Anwendung(2).
> Die Installation von (2) hat (1) nicht weiter zu beeinflussen. Punkt.
> Sondern die Installation von (2) hat auf (1) aufzubauen.

Da hast Du recht. Bei Debian ist diese Trennung
praktisch nicht vorhanden :-(

> Das Problem ist, daß ein dependency-System zu wenig Informationen hat.
?? Nö, wenn's richtig gebaut ist, nicht.
Es ist ein Baum von Abhängigkeiten. Wenn es ein großer
Baum ist, sind halt Fehler drin und es Sache der
Paketverwaltung mit den Fehlern gut umzugehen.

> Folglich ist mir das Prinzip der Isolation sympathischer.
> Hier das (1), dort die (2). (2) darf (1) nutzen, mehr auch nicht.
> Das wärs dann auch schon, viel mehr läßt sich leider wegen der
> Abhängigkeit der (2) von (1) nicht isolieren. (Hier bestünde dann die
> Möglichkeit VMs zu nutzen, welche eine weitere Isolations-ebene bereit
> stellen, zumindest theoretisch)

Das Grundsätzliche Problem bleibt. Auch Dein OS mußt Du
über kurz oder lang pflegen sprich updaten und
verändern. Und irgendwann kippt dann Deine Applikation
hinten über weil sich ein Interface oder so geändert
hat. Und Schnittstellen ändern sich schneller als man
denkt. Gestern war ein int für ne Adresse noch völlig
ausreichend. Im Zeitalter von IPV6 ist dem leider nicht
mehr so.

Toby