[linux-l] rpm

[Jan Krüger]

Tobias Schlottke wrote:
> 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

Ähem, es erweitert das Unix-Konzept und scheint der Weg zu sein, auf 
welchen sich die Distribution komplexer Anwendungen begibt.
Siehe hierzu OpenPKG und die Distribution von Kolab,
oder /package von djb oder Ansatz von DragonflyBSD.

> führt im Extremfall für 50 Applikationen zu 50 libc's
> etc. D.h. man hat n mal (fast) gleiches nebeneinander.

Sehr wohl. Dies "garantiert" zwar Funktionalität, wirft damit jedoch 
neue Probleme auf: Was ist, wenn ein Sicherheitsproblem in der 5 mal 
auf dem System vorhandenen library auftritt?

Der von Dir geschilderte Extremfall ist nach meiner Ansicht wirklich 
ein Extremfall. i.d.R. ist die Zahl der Anwendungen beschränkt, 
besonders bei Server-Anwendungen in der Größenordnung von ca. 1 bis 5 
je Server, bei Desktops sind es etwas mehr, vielleicht 10.

> 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".

Und dann?

>>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 :-(

Susie, Rotkäppchen und Company unterscheiden sich da nicht.
Slackware schafft es nur durch sein aufs wesentliche Beschränkte 
Auftreten.
Die *BSDs leuchten in dieser Hinsicht.

>>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.

Was die Sache unnötig kompliziert macht, da es ja auch ohne geht ;)

>>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.

Jo.

> Und irgendwann kippt dann Deine Applikation
> hinten über weil sich ein Interface oder so geändert
> hat.

Ich pflege natürlich nicht nur das OS sondern auch die Anwendung.
Folglich sollte das Problem nicht so schlimm auftreten, falls doch, so 
ist wohl langsam an der Zeit entweder das OS oder die Anwendung zu 
wechseln oder beides auf dem Stand zu lassen, auf welchem sie 
funktionieren und in ein Drumherum zu wrappen (z.b einen IPV6 zu IPV4 
konvertierer vorzuschalten)

> 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.

Gruß
Jan