Re: [gentoo-amd64] Re: Update config files

[Mark Haney]

Duncan wrote:
> 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.
>
>
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
[phone]

-- 
gentoo-amd64@g.o mailing list