Am Thursday 21 April 2011 schrieb Sven Hartge: > Martin Steigerwald <Martin@lichtvoll.de> wrote: > > Am Wednesday 20 April 2011 schrieb Sven Hartge: > >> Marc Haber <mh+debian-user-german@zugschlus.de> wrote: > >>> On Sat, 2 Apr 2011 15:41:48 +0200, Sven Hartge <sven@svenhartge.de> wrote: > >> >> Vorteil von etckeeper: In den Workflow von Debian integriert, so > >> >> dass man nichts manuell machen muss. > >> > > >> > Wie ist denn der Workflow von Debian beim Bearbeiten von Files > >> > innerhalb von /etc? > >> > >> Ich meinte damit: Klinkt sich via /etc/apt.conf.d/ in den > >> Paketmanager ein und kann somit durch entsprechende Hooks > >> automatische Commits vornehmen, wenn Pakete de/installiert werden. > > > > Genau den Teil kapiere ich nicht: Soweit ich hier raus las, legt es > > etckeeper darauf an, bis auf einige ignorierte Dateien *alle* Dateien > > in das VCS einzuchecken? > > > > Wozu? > > Wozu nicht? Das erklärte ich doch bereits: Das macht es wesentlich schwerer, meine eigenen Änderungen herauszufiltern. > > Ich mach einfach ein bzr init und füge dann nur die Dateien dazu, die > > ich auch *ändere*. Wenn ich dann mit bzr branch einen Branch anlege, > > hab ich übersichtlich nur das, wo ich auch hingefasst habe. Ich nehme > > außerdem Dateien dann mit bzr remove --keep aus dem VCS heraus, wenn > > ich meine Anpassungen daran zurücknehme. > > > > Oder andersherum: Was zum Geier interessieren mich die > > Konfigurationsdateien, die ich *nie* angefasst hab? > > Nicht nur du fast Konfig-Files an, auch der Paketmanager macht dies. > Das möchte zumindest ich auch rückverfolgt wissen. Okay. Aber wozu? Warum interessiert Dich, dass der Paketmanager eine Konfigurations-Datei aktualisierte, die Du nie angefasst hast? Hmmm, ich hatte das mal mit /boot, das ich auch mit Bazaar verwaltete. Da hatte ich sogar die Binärdateien vom GRUB / GRUB 2 sowie sämtliche Listen mit drin. mit drin. Bis ich merkte, dass ich das nie brauchte und mich nur die menu.lst / grub.cfg und die device.map interessierte. Selbst jetzt nachdem ich mal aufräumte, hab ich noch Zeug drin, der mich nicht die Bohne interessiert: martin@shambhala:~/Zeit> bzr checkout /boot martin@shambhala:~/Zeit> ls -lR boot boot: insgesamt 204 -rw-r--r-- 1 martin martin 99227 21. Apr 18:30 config-2.6.38.2-tp42- snapshot-atop-dirty -rw-r--r-- 1 martin martin 99205 21. Apr 18:30 config-2.6.38.3-tp42- snapshot-p1+2-dirty drwxr-xr-x 2 martin martin 4096 21. Apr 18:30 grub boot/grub: insgesamt 396 -rw-r--r-- 1 martin martin 4988 21. Apr 18:30 ascii.pff -rw-r--r-- 1 martin martin 2033 21. Apr 18:30 command.lst -rw-r--r-- 1 martin martin 825 21. Apr 18:30 crypto.lst -rw-r--r-- 1 martin martin 191 21. Apr 18:30 default -rw-r--r-- 1 martin martin 65 21. Apr 18:30 device.map -rw-r--r-- 1 martin martin 8704 21. Apr 18:30 e2fs_stage1_5 -rw-r--r-- 1 martin martin 8544 21. Apr 18:30 fat_stage1_5 -rw-r--r-- 1 martin martin 128 21. Apr 18:30 fs.lst -rw-r--r-- 1 martin martin 6931 21. Apr 18:30 grub.cfg -rw-r--r-- 1 martin martin 1024 21. Apr 18:30 grubenv -rw-r--r-- 1 martin martin 0 21. Apr 18:30 handler.lst -rw-r--r-- 1 martin martin 9568 21. Apr 18:30 jfs_stage1_5 -rw-r--r-- 1 martin martin 7690 21. Apr 18:30 menu.lst-disabled -rw-r--r-- 1 martin martin 7904 21. Apr 18:30 minix_stage1_5 -rw-r--r-- 1 martin martin 2773 21. Apr 18:30 moddep.lst -rw-r--r-- 1 martin martin 82 21. Apr 18:30 partmap.lst -rw-r--r-- 1 martin martin 17 21. Apr 18:30 parttool.lst -rw-r--r-- 1 martin martin 10720 21. Apr 18:30 reiserfs_stage1_5 -rw-r--r-- 1 martin martin 512 21. Apr 18:30 stage1 -rw-r--r-- 1 martin martin 128616 21. Apr 18:30 stage2 -rw-r--r-- 1 martin martin 128552 21. Apr 18:30 stage2_eltorito -rw-r--r-- 1 martin martin 124 21. Apr 18:30 terminal.lst -rw-r--r-- 1 martin martin 33 21. Apr 18:30 video.lst -rw-r--r-- 1 martin martin 10280 21. Apr 18:30 xfs_stage1_5 Nun, wie ich sehe, hauptsächlich GRUB 1-Zeug. Aber immerhin bekomme ich nicht mehr soviel Zeug, für das ich nicht verantwortlich bin. Nun, welchen Sinn des macht, GRUB 2 noch zu tracken, ist aber eh eine andere Frage. Hier würde etckeeper zumindest für die config-Dateien Sinn machen Gibt es etckeeper auch mit einem Opt-In-Modus, wo ich eine Liste der Dateien, Verzeichnisse / Dateimuster machen kann, die ich ihn verwalten lassen möchte, anstatt umgekehrt ausschließen zu müssen, was mich nicht interessiert und was die überwiegende Menge an Dateien ist. So aka: - config-* - grub/grub.cfg - grub/device.map für /boot? Da sehe ich nämlich einen Vorteil. Die Kernel-Konfigs vergesse ich tatsächlich manchmal einzuchecken. > > Für die Dateien, die mich interessieren, informiert mich bzr diff > > über Änderungen nach einem Paket-Upgrade. Das hätte ich vielleicht > > ganz gerne integriert. Aber wenn ich alle Dateien einchecke, dann > > bekomme ich ja auch Commits für Änderungen von Dateien, die mich gar > > nicht interessieren. Wie soll ich da auf einfache Weise noch > > herausfinden, was ich an welchen Dateien selbst geändert habe und > > was der > > Maintainer? Unterscheidet etckeeper diese beiden Fälle? > > Wenn du eine Änderung machst, dann rufst du selbst > > etckeeper commit 'blafasel geändert weil laber sülz' > > auf. Wenn der Paket-Manager etwas ändert und eincheckt, dann gibt es > eine generische Log-Meldung. > > Ehrlich gesagt, sehe ich dein Problem nicht, was du mit der > Vorgehensweise hast. Okay: Sagen wir mal ich möchte die Konfiguration von einem System auf ein neu installiertes System migrieren... wie bekomme ich mit etckeeper mit einem Befehlsaufruf *nur* meine Änderungen? Zumindest ich will dann für die neu installierten Pakete, deren Konfiguration ich nicht änderte, auch die zu dem Zeitpunkt gültige Standard-Konfiguration verwenden, anstatt eventuelle veraltete Konfigurationsdateien aus dem Quell-System drüber zu brettern. Mit meinen Ansatz könnte ich sogar einfach das alte .bzr-Verzeichnis in das neue /etc kopieren und mir mit einem bzr diff *nur* meine Änderungen anzeigen lassen und dann ggf. wieder auschecken oder die neu installierte Konfigurationsdatei von Hand anpassen oder so übernehmen. Das habe ich auch schon einmal gemacht. > > Ganz ehrlich, ich kapier den Sinn dahinter nicht, alle Dateien > > einzuchecken. > > Warum nicht? Belegt kaum Platz und erfasst alles. Keine Datei aus > versehen übersehen, weil man vergessen hat, sie hinzuzufügen. Na, wenn ich eine Datei übersehe zu committen, dann bekommt die eine generische Log-Meldung beim Commit durch etckeeper. Und wie finde ich später jemals wieder sicher heraus, dass das *meine* Änderung war? > Fire and forget. Fire and then it did something that I didn't want. > Ich liebe solche Lösungen, die mir a) nicht im Weg stehen und b) im > Hintergrund still ihre arbeit machen, ohne das ich c) dauernd an sie > denken muss. > > Kein Problem, wenn du für dich eine andere Arbeitsweise etabliert hast, > die für dich funktioniert. Na klar. Und wenn für Dich etckeeper funktioniert, warum nicht. Ich wollte halt einfach verstehen, wieso alle Dateien. Und das kapiere ich jetzt immer noch nicht. Gut, einen Vorteil hätte es: Wenn ein Paket- Upgrade eine aktuellere, aber defekte Konfigurationsdatei einspielt, dann kann ich mit etckeeper einfach die ältere Version wieder hervorholen, auch wenn ich die Datei nicht manuell eingecheckt hab. Das ist mir in den letzten Jahren aber genau gar kein Mal passiert und über snapshots.debian.org gibts ja ältere Pakete auch noch. Anyway, ich mach mich jetzt auf... lese aber gerne noch Antworten dazu, wenn ich wieder Internet-Zugang und Muse dafür hab. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.