Duncan wrote:
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.
You know, personally, I really _dislike_ getting flamed from a post
almost a month old. For the record, I _have_ read the documentation.
But for those of us who've done this a long time, the documented way
isn't always the _best_ way. I asked only to see if there was another
possibly better method of handling configuration files. I was not aware
of dispatch-conf at the time as I had been using etc-update.
I simply do not have time to re-read the documentation every other day
to keep up with those types of changes. If I did, I wouldn't have time
to do any work.
--
Interdum feror cupidine partium magnarum Europae vincendarum
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
--
[email protected] mailing list
