rpm overwriting config files again

[Jeffrey Johnson]

> On May 30, 2015, at 11:19 PM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
> On Fri, May 29, 2015 at 23:22:39 -0400, Jeffrey Johnson wrote:
> 
>> You do realize that RPM5 embeds libgit2 sufficiently well to perform
>> a commit that git(1) understands?
> 
> No... any docs? examples? How to use it? Can't find anything except
> rpmgitdebug, nothing appropriate in iosm, so I'm assuming this
> particular usage scenario is possible, but not yet available, is it?
> 

libgit2 is embedded like all other embeddings as a macro expansion

	%{git OPTIONS ARGS:BODY}

You can just as easily use %(git …) as %{git …};

There’s a hunk of code in rpmdb that will expand macros (and run git)
immediately after a header is added or deleted in an rpmdb. This is
currently how /var/lib/hrmib is populated for snmpd purposes. Files
could be managed much like etckeeper does as part of an
installation.

Meanwhile libgit2 hasn’t a stable AP: the code use to break monthly. I
am building rpm directly against HEAD of libgit2: that isn’t likely
going to be possible for any distro.

Meanwhile there’s no reason whatsoever that you can’t attempt
an etckeeper-like mechanism with a modest amount of scripting.

The harder problem for me is that RPM is expected to Just Work
in empty chroot’s, on bare metal hardware, and without git as
an install prereq. That is/was the reason for embedding libgit2.

>> Discusssing Newer! Better! Bestest!
>> %config handling, with (.rpmnew/.rpmorig/.rpmsave) handling is
>> so so so last century ...
> 
> Indeed it is. I'm tired of handling all of this manually.
> 
> With monotonically increasing versions of packages installed (i.e. only
> upgrades, no downgrades), this should be relatively simple:
> - keep some branch for original %configs (.rpmnew ones),
> - keep master branch for user-modified %configs (.rpmorig and .rpmsave),
> - try to git-merge changes on update (which would often fail, especially
>  when updating very old package with multiple changes along the way -
>  such files might be left for manual git merge/resolve).
> 
> To properly support downgrades, rebase is needed to insert a file
> between older and newer one, and some tags to distinguish version.
> 

git, not rpm, will be the tool to do rebasing etc. rpm can/will automate
some very simple steps much like etckeeper to handle %config files,
and perhaps add some options to do a diff with —query, or a merge
with —install.

> 
> BTW, referring to the main subject:
> https://www.redhat.com/archives/rpm-list/2003-May/msg00426.html
> 

*shrug* The %config handling in RPM was exactly as broken 12 years ago
as it is now. I see no important reason to change because it will lead to several
years of questions and diagnoses simply because some change exists.

73 de Jeff


> -- 
> Tomasz Pala <gotar at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en