Rcrpmconfigcheck rpmsave rpmnew
Autoren: versa, }-Tux-{, StephanS, oc2pus, taki
Was mache ich denn, wenn die conf-files komplett unterschiedlich sind? Bei mir z.B die Datei: /etc/cups/classes.conf und /etc/cups/classes.conf.rpmnew
Erstere sieht so aus: Code:
# Class configuration file for CUPS v1.1.20 # Written by cupsd on Fr 01 Apr 2005 13:09:32 CEST
letztere so:
# # "$Id: classes.conf,v 1.13 2004/02/25 20:15:27 mike Exp $" # # Sample class configuration file for the Common UNIX Printing System # (CUPS) scheduler. # # Copyright 1997-2004 by Easy Software Products, all rights reserved. # # These coded instructions, statements, and computer programs are the # property of Easy Software Products and are protected by Federal # copyright law. Distribution and use rights are outlined in the file # "LICENSE.txt" which should have been included with this file. If this # file is missing or damaged please contact Easy Software Products # at: # # Attn: CUPS Licensing Information # Easy Software Products # 44141 Airport View Drive, Suite 204 # Hollywood, Maryland 20636-3111 USA # # Voice: (301) 373-9603 # EMail: cups-info@cups.org # WWW: http://www.cups.org # ######################################################################## # # # This is a sample class configuration file. This file is included # # from the main configuration file (cups.conf) and lists all of the # # printer classes known to the system. # # # ######################################################################## # # Each class starts with a <Class name> definition. Class names # can be up to 128 characters in length and are *not* case sensitive. # # One <DefaultClass name> entry can appear in this file; if you don't # define a default destination, the first printer or class becomes # the default. # #<Class sample> # # Info: the description for the class. # #Info Acme LaserPrint 1000 Printers # # Location: the location of the printer. # #Location Room 101 in the activities building # # State: sets the initial state of the class. Can be one of the # following: # # Idle - Class is available to print new jobs. # Stopped - Class is disabled but accepting new jobs. # #State Idle # # StateMessage: sets the printer-state-message attribute for the class. # #StateMessage Class is idle. # # Accepting: is the class accepting jobs? # #Accepting Yes #Accepting No # # # Printer: adds a printer to the class. # #Printer sample #Printer sample@host2 #</Class> # # End of "$Id: classes.conf,v 1.13 2004/02/25 20:15:27 mike Exp $". #
1.) Was mache ich denn jetzt mit den beiden? Den Inhalt der rpmnew in die andere kopieren? 2.) Und was mache ich mit den ganzen *.rpmorig?
naja die beiden kannst du eigentlich so lassen wie sie sind (anscheinend verwendest du kein cups...) wobei die neue conf schon besser dokumentiert ist...
mfg }-Tux-{
Noch eine Frage zu dem rpmorig-Dateien. Ooo startet ohne Probleme. Inwieweit muss ich die Dateien checken, bzw. vor allem auf was? Auskommentierte Sachen kann ich doch sicher lassen, oder? Laut: http://portal.suse.de/sdb/de/1997/10/ke_rpm.html sollen die Dateien gelöscht werden. Richtig? Danke.
Und dazu noch eine Frage, bevor ich mir einen reboot getraue. Ich poste hier mal einen Teil meiner SuSEconfig-Ausgabe: Code:
... Executing /sbin/conf.d/SuSEconfig.kdm3... ATTENTION: You have modified /etc/opt/kde3/share/config/kdm//kdmrc. Leaving it untouched... You can find my version in /etc/opt/kde3/share/config/kdm//kdmrc.SuSEconfig... Executing /sbin/conf.d/SuSEconfig.libxml2... ...
Ist das so in Ordnung?
Die Meldung von Suseconfig bzgl. kdmrc ist kein Fehler, sondern nur ein Hinweis. Kannst du ignorieren, bzw. falls du auf KDE 3.4 geupdatet hast, dann muss das das unter SuSe 9.1 so sein, um zu funktionieren.
Am besten installierst du dir kdiff, damit kannst du dann deine ganze rpmnew, rpmorig usw. Datein vergleichen. Damit bringst du dann die ohne rpm*-Endung auf den neuesten Stand und loeschst diejenigen mit rpm*-Endungen. Bisschen laestig ist das schon, aber kein wirkliches Problem.
StephanS hat Folgendes geschrieben: Die Meldung von Suseconfig bzgl. kdmrc ist kein Fehler, sondern nur ein Hinweis. Kannst du ignorieren, bzw. falls du auf KDE 3.4 geupdatet hast, dann muss das das unter SuSe 9.1 so sein, um zu funktionieren.
das ist nicht ganz richtig Smile
seine Version wurde modifiziert, deshalb wird NICHT die neue Konfigdatei erstellt, er MUSS die abgleichen.
Deine Anmerkung ist korrekt, dann und nur dann wenn man KEINE Änderungen selbst durchgefüht hat, dann wird eine gültige kdmrc erstellt für kde-3.4.
SuSE speichert in /var/adm irgendwo die md5sum aller Konfigurationsdateien und überschreibt nur wenn sie original sind!
Siehe auch die SuSE-SDB und man rpm dazu !!
Das ist jetzt ein bisschen OT, aber ich denke, trotzdem interessant:
Die kdmrc wurde bei mir auch nicht aktualisiert, weil ich meine verändert hatte. Wer im KDE-Forum hier mitgelesen hat, wird wissen, dass die kdmrc aus dem RPM für 3.4 fehlerhaft war. Ich hatte keine Probleme, WEIL meine nicht überschrieben wurde.
Das soll jetzt aber keine Aufforderung sein, entsprechende Meldungen von RPM zu ignorieren. Bei der kdmrc war es ein glücklicher Zufall. Es kann aber auch mal was wichtiges drin sein, was man übernehmen muss. Das muss man dann im Einzelfall prüfen.
Eine Frage hätte ich dazu noch: Nicht immer legt RPM eine .rpmnew an. Manchmal sichert es die alte Konfigurationsdatei als .rpmold oder .rpmsave. Wonach richtet sich, ob die alte umbenannt und die neue installiert oder die neue unter anderem Namen installiert wird? Bestimmt das der Packager im Specfile?
taki hat Folgendes geschrieben: Eine Frage hätte ich dazu noch: Nicht immer legt RPM eine .rpmnew an. Manchmal sichert es die alte Konfigurationsdatei als .rpmold oder .rpmsave. Wonach richtet sich, ob die alte umbenannt und die neue installiert oder die neue unter anderem Namen installiert wird? Bestimmt das der Packager im Specfile?
liest du hier:
Danke Oc2pus. Dann hat mir also die noreplace-Kennung den Stress beim kde-Upgrade erspart Razz Gruß, Taki
