improving rpm

[Neal Becker]

rpm has served us well, as have the tools that have grown around it (yum,
smart, etc.).

One thing that is not currently addressed well is how to track local changes
to config files.  For now, rpm just punts, and not very intelligently. 
When a package is updated, it just creates either config.rpmnew or
config.rpmsave.  It is not intelligent - it creates these unconditionally
even if there is no actual change to the installed file.

I used to try to check these and see if there were important changes - but
now I just do what probably 99% of you do, which is just ignore it and hope
nothing breaks.

I was quite interested when I saw the announcement of conary, which solves
this problem by allowing local changes tracked as patches.

It occurs to me that we can get most of the benefit if rpm is modified to do
two things.

1) Don't create needless .rpmsave/.rpmnew if there is no change
2) Attempt to merge changes, in the manner of a modern revision control
system.

[Ralf Ertzinger]

Hi.

Neal Becker <ndbecker2(a)gmail.com&gt; wrote:

>  1) Don't create needless .rpmsave/.rpmnew if there is no change
If RPM does this even when the file has not changed (same MD5 sum)
it is a packaging bug/oddity of some kind.

>  2) Attempt to merge changes, in the manner of a modern revision
> control
>  system. 
This may be hard to impossible to accomplish.

-- 
I'm a bisexual who just hasn't had any homosexual experiences.
		-- Brett Anderson

[n0dalus]

On 7/13/06, Ralf Ertzinger <fedora(a)camperquake.de&gt; wrote:
>  > 1) Don't create needless .rpmsave/.rpmnew if there is no
> change
>
>  If RPM does this even when the file has not changed (same MD5 sum)
>  it is a packaging bug/oddity of some kind.
>  
I think it happens whenever timestamp or permissions change as well,
even if the md5sum is the same. So, it could be the intended
behaviour.

n0dalus.

[Nicolas Mailhot]

Le Jeu 13 juillet 2006 04:25, n0dalus a écrit :
>  On 7/13/06, Ralf Ertzinger <fedora(a)camperquake.de&gt; wrote:
> > > 1) Don't create needless .rpmsave/.rpmnew if there is no change
> >
> > If RPM does this even when the file has not changed (same MD5 sum)
> > it is a packaging bug/oddity of some kind.
> >
>
>  I think it happens whenever timestamp or permissions change as well,
>  even if the md5sum is the same. So, it could be the intended
>  behaviour. 
I sure hope we're not producing rpmfoo files just because of a timestamp
mismatch

-- 
Nicolas Mailhot

[Avi Kivity]

Nicolas Mailhot wrote:
>  I sure hope we're not producing rpmfoo files just because of a timestamp
>  mismatch
>  
For x86_64, we do, for every config file in both i386 and x86_64 packages.

It's awful.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171279

And it will stay awful.

-- 
error compiling committee.c: too many arguments to function

[Nicolas Mailhot]

Le mercredi 12 juillet 2006 à 15:24 -0400, Neal Becker a écrit :

>  1) Don't create needless .rpmsave/.rpmnew if there is no change
Isn't it already supposed to do this ? (though if I look
at /etc/ld.so.conf, probably not)

>  2) Attempt to merge changes, in the manner of a modern revision
> control
>  system. 
This is a 100%-proof recipe for disaster, even if conf files where all
in structured format like XML with full grammar available

Regards,

-- 
Nicolas Mailhot

[Adam Jackson]

Nicolas Mailhot wrote:
>  Le mercredi 12 juillet 2006 à 15:24 -0400, Neal Becker a écrit :
>  
> > 1) Don't create needless .rpmsave/.rpmnew if there is no change
>  
>  Isn't it already supposed to do this ? (though if I look
>  at /etc/ld.so.conf, probably not)
>  
> > 2) Attempt to merge changes, in the manner of a modern revision control
> > system.
>  
>  This is a 100%-proof recipe for disaster, even if conf files where all
>  in structured format like XML with full grammar available 
You are encouraged to take a look at how Gentoo manages with etc-update. 
  It's quite usable.  It doesn't automerge by default, of course, but 
the UI is far better than the .rpmsave business.

- ajax

[seth vidal]

On Wed, 2006-07-12 at 14:52 -0400, Adam Jackson wrote:
>  Nicolas Mailhot wrote:
>  > Le mercredi 12 juillet 2006 à 15:24 -0400, Neal Becker a écrit :
>  > 
>  >> 1) Don't create needless .rpmsave/.rpmnew if there is no change
>  > 
>  > Isn't it already supposed to do this ? (though if I look
>  > at /etc/ld.so.conf, probably not)
>  > 
>  >> 2) Attempt to merge changes, in the manner of a modern revision control
>  >> system.
>  > 
>  > This is a 100%-proof recipe for disaster, even if conf files where all
>  > in structured format like XML with full grammar available
>  
>  You are encouraged to take a look at how Gentoo manages with etc-update. 
>    It's quite usable.  It doesn't automerge by default, of course, but 
>  the UI is far better than the .rpmsave business.
>   
How well does it handle un-attended operation?

-sv

[Aron Griffis]

seth vidal wrote:  [Wed Jul 12 2006, 04:26:26PM EDT]
>  > You are encouraged to take a look at how Gentoo manages with
> etc-update. 
>  > It's quite usable.  It doesn't automerge by default, of course, but 
>  > the UI is far better than the .rpmsave business.
>  > 
>  
>  How well does it handle un-attended operation? 
It doesn't.  Portage is designed for unattended operation too.
etc-update is a tool you run afterward to handle the config conflicts.

Aron

[seth vidal]

On Wed, 2006-07-12 at 16:42 -0400, Aron Griffis wrote:
>  seth vidal wrote:  [Wed Jul 12 2006, 04:26:26PM EDT]
>  > > You are encouraged to take a look at how Gentoo manages with etc-update. 
>  > > It's quite usable.  It doesn't automerge by default, of course, but 
>  > > the UI is far better than the .rpmsave business.
>  > > 
>  > 
>  > How well does it handle un-attended operation?
>  
>  It doesn't.  Portage is designed for unattended operation too.
>  etc-update is a tool you run afterward to handle the config conflicts.
>   
So then this shouldn't be tied into rpm at all. just an external tool to
deal with config file changes.

-sv

[Jason L Tibbitts III]

> >>>> "sv" == seth vidal
> <skvidal(a)linux.duke.edu&gt; writes: 
sv> So then this shouldn't be tied into rpm at all. just an external
sv> tool to deal with config file changes.

I've been running 60 lines of Perl to inform me of config file changes
and send me diffs for nearly a decade now.  It just calls rpm -qac and
looks for .rpm{save,new} files.  Anyway, it's not as if IRIX didn't
have this for ages.  It should be pretty easy for someone who knows
what they're doing to cook up an interface which integrates a basic
merge tool and a quick documentation browser.

 - J<

[Rahul Sundaram]

seth vidal wrote:
>  On Wed, 2006-07-12 at 16:42 -0400, Aron Griffis wrote:
> > seth vidal wrote:  [Wed Jul 12 2006, 04:26:26PM EDT]
> >>> You are encouraged to take a look at how Gentoo manages with etc-update. 
> >>> It's quite usable.  It doesn't automerge by default, of course, but 
> >>> the UI is far better than the .rpmsave business.
> >>>
> >> How well does it handle un-attended operation?
> > It doesn't.  Portage is designed for unattended operation too.
> > etc-update is a tool you run afterward to handle the config conflicts.
> >
>  
>  So then this shouldn't be tied into rpm at all. just an external tool to
>  deal with config file changes.
>  
>  -sv
>  
Seth,

I heard urpmi in Mandriva offers some interactive choices with this. 
Maybe you can take a look at that and see if similar features can be 
implemented in Yum.

Rahul

[Tom]

On 12 3:40:S, seth vidal wrote:
>  On Wed, 2006-07-12 at 16:42 -0400, Aron Griffis wrote:
>  > seth vidal wrote:  [Wed Jul 12 2006, 04:26:26PM EDT]
>  >
>  > > > You are encouraged to take a look at how Gentoo manages
>  > > > with etc-update. It's quite usable.  It doesn't automerge
>  > > > by default, of course, but the UI is far better than the
>  > > > .rpmsave business.
>  > >
>  > > How well does it handle un-attended operation?
>  >
>  > It doesn't.  Portage is designed for unattended operation too.
>  > etc-update is a tool you run afterward to handle the config
>  > conflicts.
>
>  So then this shouldn't be tied into rpm at all. just an external
>  tool to deal with config file changes.
>
>  -sv 
   FWIW,  etc-update-20020731-6mdk.noarch.rpm   installs and works 
properly on FC6-test if y'all want to take a look at it.
ftp://fr2.rpmfind.net/linux/MandrakeCooker/community/i586//media/contrib/...

$ which etc-update
/usr/bin/etc-update

    Gives these choices;

1) Upgrade to new /etc/ntp.conf.rpmnew
2) Keep existing /etc/ntp.conf
3) Merge the two files
4) Show the difference between the two files again
5) Skip (keep all files)
  OR
6) Quit etc-update

Type (1, 2, 3, 4, 5 or 6): 6

-- 
    Tom Brinkman                   Corpus Christi, Texas

[Stephen John Smoogen]

On 7/12/06, Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le mercredi 12 juillet 2006 à 15:24 -0400, Neal Becker a écrit :
>
>  > 1) Don't create needless .rpmsave/.rpmnew if there is no change
>
>  Isn't it already supposed to do this ? (though if I look
>  at /etc/ld.so.conf, probably not)
>
>  > 2) Attempt to merge changes, in the manner of a modern revision control
>  > system.
>
>  This is a 100%-proof recipe for disaster, even if conf files where all
>  in structured format like XML with full grammar available
>  
The only way I have seen this 'work' is where the end result config
file is built from 'other' config files. In this case you would have a
default config, an repository patch, and a local patch. The master
ninja configurator would then build its new config by superceeding
default by any repository patches and those would be replaced by
local. This would then would build out the new configuration file.

The problems were you had to know that 'master ninja configurator'
controlled all of its config files and didn't make local changes.. and
you had to write m4 for each type of end-result config file that would
be created. [By 3 insane cs students who spent too long reading the
sendmail source code to find Cthulhu's Code.]

-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator

[Robert Scheck]

Hello Stephen,

On Wed, 12 Jul 2006, Stephen John Smoogen wrote:
>  The only way I have seen this 'work' is where the end result
> config
>  file is built from 'other' config files. In this case you would have a
>  default config, an repository patch, and a local patch. The master
>  ninja configurator would then build its new config by superceeding
>  default by any repository patches and those would be replaced by
>  local. This would then would build out the new configuration file. 
this sounds very similar to what is OpenSuSE currently practising by the
use of SuSEconfig as far as I could see in the latest release. Nevertheless
it could be really a nice feature - but only when we don't have something
equivalent to SuSEconfig... ;-)

On Wed, 12 Jul 2006, seth vidal wrote:
>  Wow, I'm dizzy from all the spin. 
Ha Seth, never saw you speechless before. Didn't think that, it would be
such easy ;-)


Greetings,
  Robert

[Camilo Mesias]

Nicolas

> > 2) Attempt to merge changes, in the manner of a modern revision
> control
> > system.
>  
>  This is a 100%-proof recipe for disaster, even if conf files where all
>  in structured format like XML with full grammar available 
I don't think it has to be a disaster.

If a package is frequently updated, or has a large config file which has 
minimal changes, then I imagine the logic to patch the config file would 
be simple.

If the situation is complex, we can detect it and make suggestions. 
Maybe even fall back to existing behaviour.

I think it's an interesting idea. What's the harm in offering the user 
the choice between new config, old config, merged changes?

-Cam

-- 

                                                                      <--
camilo(a)mesias.co.uk

[Peter Gordon]

Cam wrote:
>  I think it's an interesting idea. What's the harm in offering
> the user
>  the choice between new config, old config, merged changes? 
Perhaps a tool akin to the functionality of Gentoo's etc-update [1,2] would
prove useful?

[1] http://gentoo-wiki.com/HOWTO_etc-update
[2] http://gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=4#doc_...
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.

[Nicolas Mailhot]

Le mercredi 12 juillet 2006 à 21:12 +0100, Cam a écrit :
>  Nicolas
>  
>  >> 2) Attempt to merge changes, in the manner of a modern revision control
>  >> system.
>  > 
>  > This is a 100%-proof recipe for disaster, even if conf files where all
>  > in structured format like XML with full grammar available
>  
>  I don't think it has to be a disaster.
>  
>  If a package is frequently updated, or has a large config file which has 
>  minimal changes, then I imagine the logic to patch the config file would 
>  be simple. 
Except you can't assume the user will always do a n -> n+1 upgrade and
not wait several years before doing a FCn -> FCn+X update

Except you can't assume the user didn't change the conf file manually
between updates

Except many conf files allow you to express the same thing in different
ways, so you have to actually parse and understand the meaning of a file
before safely patching it.

Except sometimes configuration is stacked with conf.d and other such
things so you need to parse all the other files too before changing one
of them

Except you need to track non-active info such as comments

>  If the situation is complex, we can detect it and make suggestions.
rpm is designed to run unattended

>  Maybe even fall back to existing behaviour. 
the existing conf file may be invalid for the new version of the app.

>  I think it's an interesting idea. What's the harm in offering
> the user 
>  the choice between new config, old config, merged changes? 
rpm is designed to run unattended

If you want to have a small idea of what "patching conf files" really
means I invite you to read the dejavu rpm spec. And I'm only doing small
changes on a conf file with very few verbs, stable grammar, no
interactions between conf directives, and structured content.

-- 
Nicolas Mailhot

[Camilo Mesias]

Nicolas

>  Except you can't assume the user will always do a n -> n+1
> upgrade and
>  not wait several years before doing a FCn -> FCn+X update
>  
>  Except you can't assume the user didn't change the conf file manually
>  between updates
>  
>  Except many conf files allow you to express the same thing in different
>  ways, so you have to actually parse and understand the meaning of a file
>  before safely patching it.
>  
>  Except sometimes configuration is stacked with conf.d and other such
>  things so you need to parse all the other files too before changing one
>  of them
>  
>  Except you need to track non-active info such as comments 
All valid reasons why an automatic merge may not be possible in all 
cases. That's not to say that it wouldn't work in many cases, or that it 
would be somehow worse than not bothering at all.

> > If the situation is complex, we can detect it and make
> suggestions.
>  
>  rpm is designed to run unattended 
That needn't change. rpmsave and rpmnew are suggestions, and the file 
that remains after update is the best guess. Interactivity would be a 
nice bonus for a modern OS but needn't be a deal breaker.

>  If you want to have a small idea of what "patching conf
> files" really
>  means I invite you to read the dejavu rpm spec. And I'm only doing small
>  changes on a conf file with very few verbs, stable grammar, no
>  interactions between conf directives, and structured content. 
I'm not sure how closely an rpm spec would match a realistic use case 
for end user OS administration. But even so, going from one version to 
the another, and applying a patch (adding a few lines, deleting some or 
changing them) could either patch successfully, or fail. In the event of 
failure we have an 'rpmsave'.

-Cam

-- 

                                                                      <--
camilo(a)mesias.co.uk

[Nicolas Mailhot]

Le Jeu 13 juillet 2006 00:47, Cam a écrit :

>  I'm not sure how closely an rpm spec would match a realistic use
> case
>  for end user OS administration. But even so, going from one version to
>  the another, and applying a patch (adding a few lines, deleting some or
>  changing them) could either patch successfully, or fail. 
Successfuly as in "I dumped some string I don't understand in a file
checking the three lines before and after, I have zero idea if this string
interacts with the lines I've checked in this file or others (in this file
or another one), and I hope if I did  something wrong the admin will
notice it before the app starts eating his data or opens a hole in system
security"

Gives a new definition to bleeding edge and raw hide

-- 
Nicolas Mailhot

[Till Maas]

Am Mittwoch, 12. Juli 2006 22:32 schrieb Nicolas Mailhot:
>  Le mercredi 12 juillet 2006 à 21:12 +0100, Cam a écrit : 
>  > I think it's an interesting idea. What's the harm in
> offering the user
>  > the choice between new config, old config, merged changes?
>
>  rpm is designed to run unattended
>
>  If you want to have a small idea of what "patching conf files" really
>  means I invite you to read the dejavu rpm spec. And I'm only doing small
>  changes on a conf file with very few verbs, stable grammar, no
>  interactions between conf directives, and structured content. 
rpm could just behave the same way as before but also create an .rpmmerged 
file if the old and new config file are different. This way one can inspect 
the .rpmmerged file and fix it, move it to actuall config file or discard it. 
Nevertheless it can make an update easier in many cases where only simple 
changes in the config file were performed by the user. Maybe after some time 
we get some experience how good this merging works and use it automatically.

Regards,
Till

[Rudolf Kastl]

2006/7/14, Till Maas <opensource(a)till.name&gt;:
>  Am Mittwoch, 12. Juli 2006 22:32 schrieb Nicolas Mailhot:
>  > Le mercredi 12 juillet 2006 à 21:12 +0100, Cam a écrit :
>
>  > > I think it's an interesting idea. What's the harm in offering the user
>  > > the choice between new config, old config, merged changes?
>  >
>  > rpm is designed to run unattended
>  >
>  > If you want to have a small idea of what "patching conf files" really
>  > means I invite you to read the dejavu rpm spec. And I'm only doing small
>  > changes on a conf file with very few verbs, stable grammar, no
>  > interactions between conf directives, and structured content.
>
>  rpm could just behave the same way as before but also create an .rpmmerged
>  file if the old and new config file are different. This way one can inspect
>  the .rpmmerged file and fix it, move it to actuall config file or discard it.
>  Nevertheless it can make an update easier in many cases where only simple
>  changes in the config file were performed by the user. Maybe after some time
>  we get some experience how good this merging works and use it automatically.
>
>  Regards,
>  Till
>
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

a few years ago i have packaged a solution for this called etc-update
with rpm support on newrpms.sunsite.dk.
you may want to look for the etc-update src rpm there...

basically its nothing but a script that prompts you for merging all of
those updated config files with the user modified ones.

the merge utility can be freely configured (i prefer meld personally
but thats not a solution for cli monkeys)

regards,
Rudolf Kastl

[Michael Schroeder]

On Wed, Jul 12, 2006 at 09:12:27PM +0100, Cam wrote:
>  I don't think it has to be a disaster.
>  
>  If a package is frequently updated, or has a large config file which has 
>  minimal changes, then I imagine the logic to patch the config file would 
>  be simple. 
If a package is frequently updated the md5sums in the rpm probably
stay the same (i.e. the config files in the rpms stay the same).
In that case rpm doesn't create .rpm{new,orig) files as well, even
if the user changed the config file in the system.
(And, of course, the system config files stays unchanged.)

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

[Toshio Kuratomi]

On Wed, 2006-07-12 at 15:24 -0400, Neal Becker wrote:
>  I was quite interested when I saw the announcement of conary, which
> solves
>  this problem by allowing local changes tracked as patches.
>  
>  It occurs to me that we can get most of the benefit if rpm is modified to do
>  two things.
>  
>  1) Don't create needless .rpmsave/.rpmnew if there is no change 
This is a bug. 
When I first started using rpm it followed its
documented behaviour... which is to not create these files.  Recently
(and by recently I mean sometime in the RHL era :-) some packages have
begun to create rpmsave/rpmnew where the md5sum of the config files are
the same between packages.

Bugs have been filed with discouraging results.  Here's one that
definitely references this issue:
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188100

This one touches on the same "user interface" issues and may be easy to
fix at the same time:
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=29470

I believe this is one of them (a bug originally filed against rpm.  The
problem was misunderstood and retargetted it against the package itself.
The package owner attempted to "fix it" and the problem became worse on
the tester's system.)
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176248

I didn't go digging through the CLOSED bugs but there may be other cases
where the former Red Hat rpm maintainer misunderstood the problem and
closed the bug as well.

>  2) Attempt to merge changes, in the manner of a modern revision
> control
>  system.
>   
This won't work.  Merging changes to config files can't be done
automatically,
1) it has to be done with knowledge of what the program that uses the
config file expects to find.
2) it often has to know what the system adminsitrator intended when they
modified the config file.

Without those pieces of information, a tool that automaticaly merges
changes is most likely going to cause extensive breakage.

-Toshio

[Michael Schwendt]

On Wed, 12 Jul 2006 13:18:58 -0700, Toshio Kuratomi wrote:

>  > 1) Don't create needless .rpmsave/.rpmnew if there is no
> change
>
>  This is a bug.  When I first started using rpm it followed its
>  documented behaviour... which is to not create these files.  Recently
>  (and by recently I mean sometime in the RHL era :-) some packages have
>  begun to create rpmsave/rpmnew where the md5sum of the config files are
>  the same between packages. 
I just wanted to shout "vim-common" (/etc/vimrc) before I looked
up the following ticket:

>  Bugs have been filed with discouraging results.  Here's one that
>  definitely references this issue:
>    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188100 
/etc/vimrc :)

[Horst H. von Brand]

Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  On Wed, 2006-07-12 at 15:24 -0400, Neal Becker wrote:
>  > I was quite interested when I saw the announcement of conary, which solves
>  > this problem by allowing local changes tracked as patches. 
>  > It occurs to me that we can get most of the benefit if rpm is
> modified
>  > to do two things. 
>  > 1) Don't create needless .rpmsave/.rpmnew if there is no
> change 
>  This is a bug.  When I first started using rpm it followed its
>  documented behaviour... which is to not create these files.  Recently
>  (and by recently I mean sometime in the RHL era :-) some packages have
>  begun to create rpmsave/rpmnew where the md5sum of the config files are
>  the same between packages. 
It was mentioned that this might reflect ownership/mode changes. I would
vote for just changing those (and printing a warning) in that case, if the
file contents is the same.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: [phone]
Universidad Tecnica Federico Santa Maria              [phone]
Casilla 110-V, Valparaiso, Chile                Fax:  [phone]

[Robert Scheck]

Hello Neal,

On Wed, 12 Jul 2006, Neal Becker wrote:
>  2) Attempt to merge changes, in the manner of a modern revision
> control
>  system. 
Jeff was (is?) thinking about a feature to do manual diffs between config
file within the RPM package and the installed config file in filesystem.

But this feature maybe (nobody knows, yet) will never reach any Fedora Core
or RHEL release, because upstream RPM could change it's license for Fedora/
Red Hat when the FAB decision mismatches with vision of RPM upstream...


Greetings,
  Robert

[seth vidal]

On Wed, 2006-07-12 at 22:19 +0200, Robert Scheck wrote:
>  Hello Neal,
>  
>  On Wed, 12 Jul 2006, Neal Becker wrote:
>  > 2) Attempt to merge changes, in the manner of a modern revision control
>  > system.
>  
>  Jeff was (is?) thinking about a feature to do manual diffs between config
>  file within the RPM package and the installed config file in filesystem.
>  
>  But this feature maybe (nobody knows, yet) will never reach any Fedora Core
>  or RHEL release, because upstream RPM could change it's license for Fedora/
>  Red Hat when the FAB decision mismatches with vision of RPM upstream...
>   
Wow, I'm dizzy from all the spin.

-sv

[Kłoczko Tomasz]

Dnia 12-07-2006, śro o godzinie 15:24 -0400, Neal Becker napisał(a):
>  rpm has served us well, as have the tools that have grown around it
> (yum,
>  smart, etc.).
>  
>  One thing that is not currently addressed well is how to track local changes
>  to config files.  For now, rpm just punts, and not very intelligently. 
>  When a package is updated, it just creates either config.rpmnew or
>  config.rpmsave.  It is not intelligent - it creates these unconditionally
>  even if there is no actual change to the installed file.
>  
>  I used to try to check these and see if there were important changes - but
>  now I just do what probably 99% of you do, which is just ignore it and hope
>  nothing breaks.
>  
>  I was quite interested when I saw the announcement of conary, which solves
>  this problem by allowing local changes tracked as patches. 
Not 100% right but IMO patch it is only another form of *.rpm{new,save}
files. For fully automated update procedures better will be extend rpm
current %trigger* script by kind of %update.
Why ? because current syntax of for example most often used %
triggerpostun is:

%triggerpostun -- <package_name> [< <version>]

instead of:

%update <versionA> <versionB>

which IMO will allow implement more precise framework for adding better
update (for example config files) procedures.

Also next thing ..
Now there is no place in rpm database where are stored all original %
config files contents. It is necessary now if rpm must be usable as PM
for Solaris 10 with zoning but .. not only for Solaris. Also will be
necessary on Linux on create by replicate any system images from system
installed files for Xen or VT implementation similar to Solaris zoning
in case non-shared part between main system resources and Xen/VT/zone
subsystem.
Why ? because many cases create this kind images requires on initial
replication %config files in original form.
If in rpm database will be stored original file (not only md5/sha
digest) create *.rpm{new,save} or patch file can be done as rpm config
parameter (stored for example in /etc/rpm/rpmrc).

Also keep in rpm database all original %config files will allow faster
maintenance system in case some bad changes or mistake removing this
kind files.

Also have some kind of infrastructure in rpm for allow commit change in
%config file to rpm database will allow:
- keep track of changes in %config files (for better system
  maintenance),
- prepare better automation for update %config files on upgrade.
Keep in rpm db changes as patches series with short comments or even as
RCS blob will be probably all what is necessary (more sophisticated VC
system will be probably overkill).

kloczek

[Jane Dogalt]

--- Neal Becker <ndbecker2(a)gmail.com&gt; wrote:
>  rpm has served us well, as have the tools that have grown around it
> (yum,
>  smart, etc.).
>  ...
>  1) Don't create needless .rpmsave/.rpmnew if there is no change
>  2) Attempt to merge changes, in the manner of a modern revision control
>  system. 
As mentioned, 1 is a bug, but for 2-

I vote for a very simple method, of not changing the important current
behaviour, but just adding the creation of .rpmpatch files, and then adding a
tool to post facto help the user with the manual merge (somewhat akin to gentoo
reference).

I.e.

rpm -Uvh [--interactive] foo.rpm
(or if no --interactive, then after the fact-
rpm --mergeconfig foo

Which would then throw up text or gui dialogs alerting the user to unmerged
config changes, and then bringing up a tool like meld(aka xxdiff).

What this seems to boil down to is a common sysadmin process, which currently
is left up to the user, instead of being streamlined and documented.  Mind you,
an argument could be made for leaving around the presumption that sysadmins
ought to be expected to know all the constituent parts.  But still, I wouldn't
mind if rpm created the patch for me, and then prodded me along the process of
invoking meld.

To ramble on further- this evokes the difference between apt/dpkg and rpm,
whereby dpkg stupidly doesn't always hold to the maxim 'default installs are
preconfigured with sane default configurations'.  However, I think the best
would be a merging of the two, and the addition to rpm of "rpm --configure foo"
which would invoke some %config script from the rpm specfile, which would
invoke the configuration tool for the package.  Then somehow combining that
diff/patch/merge business into the configuration tool for each package, would
be some work, but it would be pretty cool.

Just rambling...

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[David Lutterkort]

On Wed, 2006-07-12 at 15:24 -0400, Neal Becker wrote:
>  2) Attempt to merge changes, in the manner of a modern revision
> control
>  system. 
If you're just managing one machine, something like etc-update seems a
reasonable solution, possibly together with making /etc a
mercurial-or-whatever-your-favorite-scm-is repo.

If you manage more than one machine, chances are you are using some sort
of tool to track the configs of your machines, if not you should [1], in
which case you will track and manually merge local changes to config
files centrally. There's of course a lot of room to make the reconciling
the local .rpmnew/.rpmsave files with the site configuration easier ...

David

[1] I highly recommend puppet if you are interested in using a config
mgmt tool, http://reductivelabs.com/projects/puppet/