Re: RH tools and conf changes

[Dag Wieers <dag wieers com>]

On Fri, 22 Jul 2005, John Summerfied wrote:

> Dag Wieers wrote:
> 
> > > Then my expectations of implementation ease are assuming functionality
> > > that RPM doesn't have, and that's why you're telling me that it would be
> > > difficult to determine when to send notification?
> > > 
> > > Is that correct?
> > 
> > The problem is that what you expect is not why something happens. Sure you
> > can have RPM mail something whenever it replaces (or does not replace) a
> > configuration file. But does it matter in that cases to notify the sysadmin
> > ? In most cases it might not, but only the sysadmin knows.
> > 
> > In the end, if I have to implement something like this for you in a
> > guaranteed environment, I would let RPM send out a mail everytime an upgrade
> > happens as this will cover all cases where it might be important :) And you
> > will agree that this was not your intention.
> 
> If you want to get a sensible solution to the conundrum, make sensible
> suggestions.

I think I did :) I even gave you an implementation and said how it could 
be improved.


> Clearly, if a package has no configuration file, there's nothing to say.
> 
> If a package upgrade replaces unaltered configuration files, there's probably
> nothing to say (but there might be some exceptions).
> 
> If an upgraded package has configuration files which a user has updated, but a
> new configuration file is the same as the original unaltered file, there's
> probably nothing to say about that configuration file (but again, there may be
> exceptions).

In all these cases RPM will not create .rpmsave or .rpmnew files.


> Now, if a new configuration is different from an earlier one because comments
> have been changed or reformatted, that's a little tricker but it's still not
> hard to spot material differences in may cases.

Sure, although that depends on the format of the file. So what's next, 
cataloguing every format and make RPM know about this so diffs can be made 
sensibly ? Have packagers add this information manually ? I don't see that 
work.


> I was going to show how with a pair of FC kernels, but the output's a little
> long:
> diff -u <(egrep -v '^#' <config-2.6.12-1.1372_FC3) <(egrep -v '^#'
> <config-2.6.11-1.35_FC3) | wc -l
> 
> Here's the start, it illustrates the point well enough:
> [summer echidna boot]$ diff -u <(egrep -v '^#' <config-2.6.12-1.1372_FC3)
> <(egrep -v '^#' <config-2.6.11-1.35_FC3) | head -20
> --- /dev/fd/63  2005-07-22 15:24:11.878831680 +0800
> +++ /dev/fd/62  2005-07-22 15:24:11.893829307 +0800
> @@ -7,7 +7,6 @@
>  CONFIG_EXPERIMENTAL=y
>  CONFIG_CLEAN_COMPILE=y
>  CONFIG_BROKEN_ON_SMP=y
> -CONFIG_INIT_ENV_ARG_LIMIT=32
> 
>  CONFIG_LOCALVERSION=""
>  CONFIG_SWAP=y
> @@ -17,13 +16,11 @@
>  CONFIG_SYSCTL=y
>  CONFIG_AUDIT=y
>  CONFIG_AUDITSYSCALL=y
> +CONFIG_LOG_BUF_SHIFT=17
>  CONFIG_HOTPLUG=y
>  CONFIG_KOBJECT_UEVENT=y
>  CONFIG_KALLSYMS=y
>  CONFIG_KALLSYMS_EXTRA_PASS=y
> -CONFIG_PRINTK=y
> [summer echidna boot]$
> 
> The differences shown here are material: installing sysadmins should read this
> and use their own judgement as to their significance.
> 
> It may not be perfect, and it may require some input by packagers some times,
> but it's a start.

I don't want to sound negative, but the example has several issues:

 + the kernel config file is not a config file to the package
 + the kernel config file is never ever altered by the user
 + the kernel package is different than most other packages in that it's 
   often not just upgraded like normal packages
 + there is no real relation between 2 kernel configs of 2 different 
   kernels (the files have a different name every time)

The example doesn't fit what we previously discussed. I'm not saying this 
wouldn't be useful, it's just hard to automate and too much to ask for if 
you expect people to do things like this manual.

But instead of discussing back and forth, prove me wrong with an 
implementation :) I'm not against the idea per se, I just don't think it's 
implementable and even if it were (like discussed) it wouldn't be very 
useful (too much false reports).

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]