[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: improving rpm

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:

This one touches on the same "user interface" issues and may be easy to
fix at the same time:

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.)

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
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.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]