Re: change conffiles
On 2004-11-19 10:14:12 +0100, Richard Kemp wrote: Right, but I want to maintain my files in a package and I can't do this because these files belong to another package. That's why I ask if a method exists to be able to maintain files coming from 2 different packages (mainly fo conffiles). It would be a good idea if conf files could include a local part that would completely controlled and managed by the user. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
How to install my own conffiles like /etc/bash.bashrc or /etc/screenrc with a debian package without conflicts with the real package ? They are *conf* files, so the package installer framework will not overwrite your modified versions of these files with the versions found in newer versions of the packages without asking you first. Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
Michael Sims wrote: Have you thought about maybe taking a different approach to this altogether? I'm assuming the point of this is to make it easier to manage the configuration of a group of similar servers...or to restore the configuration of a particular server in the case of hardware failure or a system reload, right? You're right :) Personally I keep all the configuration files for my servers in a CVS module, and I use Makefiles to copy them to the right locations, set the proper permissions, and in some cases restart daemons, etc. This means all I need to do is checkout my cvs module, then run make to have the configuration files pushed out. I also have a perl helper script that does stuff like diff my files against the installed versions, etc. You may want to consider something similar...it works for me quite well. I can provide more info if you're interested. In fact I hoped that there's a method to manage that with the debian package properly. Now I'll re-examine my way of making. Thank you for your help :) -- Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
Alexis Huxley wrote: They are *conf* files, so the package installer framework will not overwrite your modified versions of these files with the versions found in newer versions of the packages without asking you first. Right, but I want to maintain my files in a package and I can't do this because these files belong to another package. That's why I ask if a method exists to be able to maintain files coming from 2 different packages (mainly fo conffiles). -- Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
Richard Kemp wrote: How to install my own conffiles like /etc/bash.bashrc or /etc/screenrc with a debian package without conflicts with the real package ? This is strongly not recommended (by some Debian doc..somewhere..), though it might be possible to divert the originals. Packages aren't supposed to mess with others' conffiles, even if they are custom built with that purpose in mind. Michael Spang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
Michael Spang wrote: Richard Kemp wrote: How to install my own conffiles like /etc/bash.bashrc or /etc/screenrc with a debian package without conflicts with the real package ? This is strongly not recommended (by some Debian doc..somewhere..), though it might be possible to divert the originals. Packages aren't supposed to mess with others' conffiles, even if they are custom built with that purpose in mind. Michael Spang I know that it's not recommended. But that would be very practical to be able to maintain its own conffiles easily. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
Richard Kemp wrote: I know that it's not recommended. But that would be very practical to be able to maintain its own conffiles easily. Maybe so. I just read the dpkg-divert manpage and it won't divert conffiles, either. So I don't think this is possible. Michael Spang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: change conffiles
Michael Spang wrote: Maybe so. I just read the dpkg-divert manpage and it won't divert conffiles, either. So I don't think this is possible. Yes, I tried with dpkg-divert but the result is very odd, I asked to the list 2 days ago but I hadn't any answer .. :( Here what I did, it carries out well the diversion (preinst) but I don't find my new file installed, or it installs my file but doesn't carry out the diversion: # Makefile of my source package files DESTDIR = $(DEBDIR)/etc install: install -d $(DESTDIR)/skel install -o root -g adm -m 664 bash.bashrc $(DESTDIR)/bash.bashrc install -o root -g adm -m 664 profile $(DESTDIR)/profile install -o root -g adm -m 664 bashrc $(DESTDIR)/skel/.bashrc install -o root -g adm -m 664 bash_profile $(DESTDIR)/skel/.bash_profile install -o root -g adm -m 664 bash_logout $(DESTDIR)/skel/.bash_logout # debian/rules export DH_COMPAT=3 configure: configure-stamp configure-stamp: dh_testdir touch configure-stamp build: build-stamp build-stamp: configure-stamp dh_testdir touch build-stamp clean: dh_testdir dh_testroot rm -f build-stamp configure-stamp rm -rf $(CURDIR)/debian/omd-base-files rm -rf ../omd-base-files_* # Add here commands to clean up after the build process. -$(MAKE) clean dh_clean install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/base-files. $(MAKE) DEBDIR=$(CURDIR)/debian/omd-base-files # Build architecture-independent files here. binary-indep: build install # We have nothing to do by default. # Build architecture-dependent files here. binary-arch: build install dh_testdir dh_testroot dh_installchangelogs dh_installdocs dh_installexamples # dh_install # dh_installmenu dh_installdebconf # dh_installlogrotate # dh_installemacsen # dh_installpam # dh_installmime # dh_installinit # dh_installcron # dh_installinfo # dh_installman # dh_link # dh_strip dh_compress # dh_fixperms # dh_perl # dh_python # dh_makeshlibs dh_installdeb dh_shlibdeps dh_gencontrol dh_md5sums dh_builddeb binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install configure # debian/preinst set -e dpkg-divert --package omd-base-files --add --rename --divert /etc/bash.bashrc.omd-bak /etc/bash.bashrc dpkg-divert --package omd-base-files --add --rename --divert /etc/profile.omd-bak /etc/profile dpkg-divert --package omd-base-files --add --rename --divert /etc/skel/.bashrc.omd-bak /etc/skel/.bashrc dpkg-divert --package omd-base-files --add --rename --divert /etc/skel/.bash_profile.omd-bak /etc/skel/.bash_profile dpkg-divert --package omd-base-files --add --rename --divert /etc/skel/.bash_logout.omd-bak /etc/skel/.bash_logout # debian/postrm set -e dpkg-divert --package omd-base-files --remove /etc/bash.bashrc dpkg-divert --package omd-base-files --remove /etc/profile dpkg-divert --package omd-base-files --remove /etc/skel/.bashrc dpkg-divert --package omd-base-files --remove /etc/skel/.bash_profile dpkg-divert --package omd-base-files --remove /etc/skel/.bash_logout -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: change conffiles
Richard Kemp wrote: Yes, I tried with dpkg-divert but the result is very odd, I asked to the list 2 days ago but I hadn't any answer .. :( Have you thought about maybe taking a different approach to this altogether? I'm assuming the point of this is to make it easier to manage the configuration of a group of similar servers...or to restore the configuration of a particular server in the case of hardware failure or a system reload, right? Personally I keep all the configuration files for my servers in a CVS module, and I use Makefiles to copy them to the right locations, set the proper permissions, and in some cases restart daemons, etc. This means all I need to do is checkout my cvs module, then run make to have the configuration files pushed out. I also have a perl helper script that does stuff like diff my files against the installed versions, etc. You may want to consider something similar...it works for me quite well. I can provide more info if you're interested. ___ Michael Sims Project Analyst - Information Technology Crye-Leike Realtors ___ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]