[gentoo-amd64] Re: Update config files

[Duncan]

Mark Haney posted <43C2D21B.9040303@××××××××××××.org>, 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


-- 
gentoo-amd64@g.o mailing list