On 25-Oct-99 Wolfgang Weisselberg wrote:
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat.
Wenn man das macht, dürfte aber die Installation eines simplen source-tgz mit configure/make/make install weniger Aufwand bedeuten.
Man verliert nur das bequeme RPM, die Abhaengigkeiten, die Trigger, ...
Wenn ich das spec-File ändern muß, ist RPM ja gerade nicht mehr als "bequem" zu bezeichnen. Abhängigkeiten werden von configure mindestens genauso zuverlässig angezeigt, im Gegenteil, wie oft schlägt RPM wegen nicht richtig erkannter alter Pakete Fehlalarm beim Installieren? Und Trigger pfuschen ohnehin nur unkontrollierbar im System rum, womit Linux wieder ein Stück näher an die Windows-Instabilitäten gerückt wird.
Und wenn man bei configure ein --prefix=/usr/local/<prg> mit angibt kann man das komplette Programm bei Bedarf mittels eines simplen rm -Rf wieder entfernen.
Ja, aber diese Idee ist alt. Abgesehen davon, dass du dann kein /etc mehr hast, keine konzentrierten Configfiles, kein /sbin/init.d/whatever ... hast du schnell einen Pfad, der laenger ist als es schoen ist oder eben doch eine Linkfarm.
Wieso kein /etc mehr? Ich habe dann für jedes Programm ein .../etc, in dem die zu dem Programm gehörige Config liegt. Die liegt da, wo jeder halbwegs logisch denkende Mensch sie sucht - beim Programm - und verschwindet bei der Deinstallation so, wie es sich gehört, auch gleich mit. Es sei denn, ich will sie z.B. bei nem Update übernehmen, dann muß ich sie halt vorher wegkopieren oder umbenennen. Konzentrierte Configfiles mögen schön sein, aber sie sorgen im Endeffekt auch bloß dafür, daß aller mögliche Müll im System rumliegt und kein Mensch mehr weiß, was wohin gehört. Liegen die Configfiles bei den Programmen, ist immer klar wo sie dazugehören. Und Müll wird auch viel weniger erzeugt. Ein /sbin/init.d/whatever hat man in 3 Minuten angelegt - wenn es denn wirklich notwendig ist. An der Ecke sollte eh nur jemand rumspielen, der auch weiß was er tut. Und aus einem skeleton-File ein neues Skript zu erzeugen ist nun wirklich einfach (zumal man auch das so weit parametrisieren kann, daß sich die Änderungen im Normalfall auf 2-3 Programmzeilen beschränken). Und wenn es schon komplizierter sein soll, kann der Programmautor auch jederzeit ein passendes File zum reinkopieren beiliegen. Und welchen Normalanwender bitteschön stört ein langer Pfad? Eine der positiven Eigenschaften von Linux ist, daß der Pfad länger als 256 Zeichen lang sein _kann_. Und die minimale Zeitverzögerung beim Aufbau einer Login-Shell oder beim Start eines Binaries nimmt der _normale_ User ohnehin nicht wahr. Wenn man dann zeitkritische Prozesse hat, kann man die immer noch entsprechend optimieren.
Nicht gut. Dazu braeuchten wir eine andere Art von Dateisystem als heute.
Funktioniert wunderbar und hat dafür gesorgt, daß mein ursprünglich auf SuSE 5.1 (!) basierendes System bis heute ohne Neuinstallation überlebt hat. Nichts gegen RPM, aber wer sowas verwendet muß sich einfach klar sein, daß er damit auch ein gutes Stück Kontrolle aufgibt. Im Endeffekt hat das Teil die gleichen Probleme wie die Windows-Installer. Da werden Abhängigkeiten nicht richtig erkannt, Deinstallationen hinterlassen Müll im System und kein Mensch weiß mehr genau, was bei der Installation eigentlich passiert ist. Ergebnis: immer unhandlichere, "zerinstalliertere" und weniger beherrschbare Systeme, die irgendwann so viele "Alterserscheinungen" angesetzt haben, daß eine Neuinstallation fällig ist. --- Erhard Schwenk <eschwenk@fto.de> - http://www.fto.de **** Jetzt neu: http://www.akkordeonjugend.de **** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com