[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: RH tools and conf changes (was: Re: Vi backspace key problem)
- From: Dag Wieers <dag wieers com>
- To: "Red Hat Enterprise Linux 4 (Nahant) Discussion List" <nahant-list redhat com>
- Subject: Re: RH tools and conf changes (was: Re: Vi backspace key problem)
- Date: Thu, 21 Jul 2005 17:01:11 +0200 (CEST)
On Thu, 21 Jul 2005, Chester R. Hosey wrote:
> On Thu, 2005-07-21 at 03:56 +0200, Dag Wieers wrote:
> > On Wed, 20 Jul 2005, Chester R. Hosey wrote:
> >
> > > On Wed, 2005-07-20 at 02:34 +0200, Dag Wieers wrote:
> > >
> > > It's a nice feature. It would be nice if up2date-with-rpm did something
> > > similar, or if RHN noted that an upgrade didn't include a configuration
> > > file update due to user changes. I'd be really impressed if RHN went to
> > > far as to provide a diff of the configuration files so the administrator
> > > could evaluate the importance without having to log in and search
> > > for .rpm{new|save|orig} files manually.
> >
> > I don't think it belongs as part of RHN, besides I don't think you can
> > implement all the complexity correctly, which would only become a
> > liability to Red Hat if they have to support it.
>
> I'm not asking for "all of the complexity". I'm asking for "RHN
> (including the tools used to implement functionality) notifies me when
> it makes a decision that may require further review." I provided an
> example of one such solution that's worked well for me in the past. It's
> a solution that specifically _doesn't_ make decisions for me. RPM is
> meant to be unattended. I suppose I fail to see how this precludes
> notifications when certain conditions arise, especially ones which are
> associated with existing well-defined program behavior.
I fail to see when this system would notify you. When a keyword in a
config-file suddenly isn't valid anymore ? When a new keyword is
introduced ? When behaviour of a program changes ? When config files move
to other locations ? Are you going to check config-files to exclude false
positives ?
That's the complexity I was talking about. Luckily this never/seldom
happens within the same release. And when doing a distribution upgrade I
much rather have the sys-admin check all services and availability than
having him rely on a uncertain logic :)
It is a nice idea to have it, and I welcome anyone to implement it. But
the way I see it now, it either is a massive undertaking or it's not
exact science. Plus the chance of missing something becomes a liability.
Don't let me discourage you to write a paper on it !
> That aside, thank you for your many contributions to the Red Hat
> community.
You're welcome :)
Kind regards,
-- dag wieers, dag wieers com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]