[linux-l] rpm

Jan Krüger jk at microgalaxy.net
Do Apr 8 13:32:15 CEST 2004


Tobias Schlottke wrote:
> On Wed, 7 Apr 2004, Jan Krüger wrote:
> 
> <Slackware>
> 
>>Falls irgendwelche Abhängigkeiten vorhanden sind, so wird in der
>>Dokumentation darauf verwiesen: "Bitte installieren sie vorher bla"
> 
> 
> ?? die Liste kann aber ganz schön lang werden, oder?
> Das ist doch auch nicht mehr als ein manuelle
> Abhängigkeitsverwaltung.

Wenn jemand unter dem System, welches von 96% der Nutzer weltweit 
genutzt wird, eine komplexe Software installiert, wie lang wird die 
Liste wohl sein?

Das ist es eben. Die Software ist auf das Betriebssystem angepaßt im 
Kontrast zu: Das Betriebssystem wird an die Software angepaßt!

Slackware bringt eine für viele Anwendungen ausreichende Basis mit.
Die Liste hielt sich bei mir bisher in Grenzen, ich nutze 
GNUcash/KDE/Mozilla/OpenOffice/KOffice und kann mich an nichts 
schlimmes bei der Installation erinnern.

> Das verstehe ich nicht. Ein Applikation X benötigt eine
> Funktion Y aus der lib Z, die aber erst ab der Version
> 47.11 enthalten ist. Was passiert denn in so einem
> Fall?

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

> Komplexe Applikationen benötigen doch zum Teil -zig
> libs. Die alle per Hand auf hinreichende Versionen zu
> überprüfen ist doch lästig, oder?

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"

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.

Das Problem ist, daß ein dependency-System zu wenig Informationen hat.
Natürlich mag es nach den Regeln OK sein, die libc oder etwas anderes, 
meinetwegen scheinbar unwichtiges, upzudaten, daß sich dadurch eine 
Funktion einer vorhanden Software (die für den Nutzer sehr wichtig 
ist) "verändern" (was der Nutzer natürlich nicht akzeptiert) kann, 
wird dabei in Kauf genommen. Halt ohne mich. Für solche Spielereien 
ist das System zu komplex. Man kann nicht mehr vorhersagen, was dann 
"verändert" wird.

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)

Also bei update von (1) ist u.U. notgedrungen auch (2) upzudaten, es 
sei denn, (1) stellt ein stabiles API zu Verfügung (wie bei 96% der 
Installierten Systeme weltweit seit Jahren der Fall, im Gegensatz zu 
gtk/gnome). Da hilft es natürlich dabei (1) auf stabile APIs zu 
beschränken. Slackware gelingt das, relativ zu den anderen 
Linux-Distris, recht gut (Debian stable mit seinen laaaangen Release 
Cyclen ja auch), übertroffen nur noch von einigen *BSDs.

>>+einfach ein funktionierendes komplett-system
>
> Sorry, aber das ist doch Unfug. Komplett ist ein System
> nie. Sonst nimm' ne DOS 3.3 Bootdisk. Ist auch komplett
> ;-)

Jupp. Liegt im Auge des Betrachters. Ich wollte damit ausdrücken, daß 
Slackware eine ausreichende Basis für viele Anwendungen zur Verfügung 
stellt. Die unbedingte Notwendigkeit von "mehr" wird durch den 
Betrachter bestimmt.


> Aber sach mal, wie funktioniert ein Update eines
> solchen Systems? rm -rf und neuinstall?

upgradepkg *

> Denn verliert man aber doch seine Konfig.

Deine config bleibt erhalten.

Gruß
Jan



Mehr Informationen über die Mailingliste linux-l