Mark Haney posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 09 Jan 2006 16:14:03 -0500:
> What's the best way to update config files? I am a big fan of RH's method > of dealing with them, and can't stand the way Debian does it, so how do > the majority of Gentoo users manage their config files? You have the answer in other posts (etc-update, or dispatch-conf, if you want to keep an RCS history of config file versions), but the very fact that you are even asking the question means you haven't read the handbook very well, and very possibly haven't read other than the install section at all! That's seriously distressing, as it means you are missing a *LOT* of *VERY* *USEFUL* information, information that will make administration of your Gentoo system *MUCH* easier! Here's the link to the contents page for the Gentoo Handbook, amd64 version: http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml I'd /seriously/ recommend that you go back and read the "Working with Gentoo" and "Working with Portage" sections. Some chapters you can safely scan, rather than actually reading them. This is particularly true of the stuff about ebuild and initscript internals. However, other parts are critical to a smooth experience as a Gentoo user (== a Gentoo system sysadmin). Gentoo is rightly recognized for having some of the BEST user documentation out there, in terms of Linux distributions. Why not use this great resource at your disposal, particularly when it makes your life as a Gentoo system sysadmin /so/ much easier? When you are done there, consider reading the manpages for emerge and portage at least. My favorite hint, covered in the handbook but I'll emphasize it here as well, is FEATURES=buildpkg, which will give you binary package backups of everything you merge. This is a big time and a** saver, allowing you to quickly revert to an older version of a package if you suspect a new one might be causing issues, then return to the new version if you find it isn't, all without forcing you to recompile the package in question, since you have a binary package, created during your original merge, available. Equally helpful, it's far easier to recover from portage or gcc breakage if you have binary packages available locally. The buildpkg feature will require 1-4 gigs of additional space, to store all those binary packages. A gig will do it, but 4 gigs allows you to keep multiple versions of the fastest moving packages around, and won't require cleaning out old versions as often. Of course, the answer to your question, how to deal with config file updates, is covered in the handbook as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
