Re: Vi backspace key problem

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Wed, 2005-07-20 at 11:49 -0400, Tom Diehl wrote:
> On Wed, 20 Jul 2005, Chester R. Hosey wrote:
> 
> > On Wed, 2005-07-20 at 02:34 +0200, Dag Wieers wrote:
> > > 
> > > That's why it is important to replace as few config-files as possible. If 
> > > a config-file (like /etc/bashrc) has not been touched, an upgrade will 
> > > replace the file with the new default.
> > > 
> > > Whatever you have put in /etc/bashrc yourself could have gone into 
> > > /etc/profile.d/
> > > 
> > > In some cases this is not possible, but it is always better to first look 
> > > at your options and weigh them, before changing a config-file. Otherwise 
> > > you have to clean up the .rpmsave and .rpmnew files yourself.
> > > 
> > > PS I've once written a tool in bash to help in cleaning up leftover files 
> > > like .rpmnew, .rpmsave and .rpmorig and I desperately need to rewrite that 
> > > in python (allowing to diff available files, verifying with rpmdb and 
> > > being smart about it in general :))
> > 
> > >From the wishlist-entries-I-don't-care-enough-to-code-myself dept:
> 
> It must not be very important to you then. :-)

Aye. I use Debian where I can, and I tend not to make changes on Red Hat
systems where I can avoid it because in my experience upgrades are
already enough work without worrying about changing configuration files.
I try to confine changes to my local configuration files, leaving
system-wide ones alone where I can.

Were I forced to deal with more than a handful of Red Hat machines, I'd
be pretty annoyed with certain RHN shortcomings. I'm already pretty
annoyed with certain RHN shortcomings.

> > When run interactively and faced with modified configuration files, dpkg
> > prompts the user and allows them to choose whether to keep the original,
> > install the upstream version, run a shell to examine the situation, or
> > examine a diff between the versions.
> 
> What happens if the updates are being performed automatically by the machine?

Under Debian updates aren't generally performed automatically by the
machine. One could invoke apt-get with the -y option, which generally
assumes the safest choice. According to the man page, "If an undesirable
situation, such as changing a held package or removing an essential
package occurs then apt-get will abort."

More complete frontends would likely use libapt and either present the
options to the user or make decisions as appropriate.

Also note that I didn't say "dpkg does everything better" but "dpkg
provides this feature." I'm not saying that X does everything Y does and
more, or X should replace Y entirely, only X does this well, perhaps Y
could do something similar.

> > 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.
> 
> So make a script that finds the .rpm{new|save|orig} files and diffs them.
> In fact it looks like dag is on the way to doing it for you.

Are you saying that it wouldn't be appropriate for the RHN interface to
let an admin know that a change might be in need of review? I'm unclear
as to whether you're saying that the feature is a bad idea, or whether
you're simply trying to cite technical reasons why it might be hard to
add this to the existing tools.

If I'm not paying for an OS or management tools I'm fine doing
scripting. If I'm paying for an OS _and_ management tools I'm going to
complain if they force me to script things that should be implemented in
the first place. Red Hat tends to ask the users to fall back to ssh and
vi where their GUI tools fail. I'm comfortable doing that, but honestly
I shouldn't _have_ to do so.

> rpm was designed to not require any interaction from the user short of
> launching the actual command. There have been many many many many many
> discussions over the years about this type of thing. Just look in the
> archives of the various Red Hat mailing lists if you need more info.
> It would be a really "Bad Thing" to incorporate anything into rpm that
> would require user interaction, since that would break a lot of
> existing installations.

Then wrap rpm, or let up2date check for such things, or rhn_check, or
something. Legacy support is important. It's also a poor excuse for
making the admin do custom scripting for something that RHN should do
reasonably. I can script this, but I feel like this would be appropriate
for RHN to provide, and it seems like a pain to have to script something
like this and push it out to many machines when it's really something
that an upgrade/update management tool should handle.

I never said that someone should modify the way RPM itself functions. I
did say that it would be nice if the feature were provided in some way.
The more I think about it, the more I feel that this is a legitimate
feature that it would be reasonable for RHN to provide.

Hell, rhn_check uses rpm-python, which itself seems to use rpmlib. A 30-
second Google search shows that rpmlib allows the user to register a
callback function for progress indication. Allow the user to register
another callback to indicate that a conflict occurred along with some
basic information (such as the filename) and let the application handle
it. Extend rpm-python to allow Python apps to register callbacks as
well, extend up2date to report the information upstream, extend RHN to
care about the additional information, and you're done.

If an app doesn't register a callback function it isn't affected at all.
You've broken nothing, and added functionality without asking every site
admin to cobble together something outside of RHN and push it out to all
of their machines.

As I see it, RHEL offers three things over other distributions: RHN, a
growing community of ISVs, and product support. It seems to me that
anything that enhances any of those three value offerings would be a
good thing for users and thus a good thing for Red Hat.

Chet