On Jun 9, 2015, at 5:50 PM, Elan Ruusamäe wrote:
> ping jbj?
>
Yes?
I don't think your change to %config handling is worth the
effort and disruption to the existing %config algorithm.
Grep the code for FA_ALTNAME (for .rpmnew) and FA_BACKUP
(for .rpmorig/.rpmsave) handling, patch as you wish.
ping jbj?
On 30.05.2015 10:30, Elan Ruusamäe wrote:
On 29.05.2015 17:43, Jeffrey Johnson wrote:
If you wish to change the behavior to, say, create foo.rpmnew instead
of foo
when the new package file is marked %config(noreplace), then patch
lib/rpmfi.c to return FA_ALTNAME instead of FA_CREATE
> On May 30, 2015, at 11:19 PM, Tomasz Pala 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
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 t
On 29.05.2015 17:43, Jeffrey Johnson wrote:
If you wish to change the behavior to, say, create foo.rpmnew instead of foo
when the new package file is marked %config(noreplace), then patch
lib/rpmfi.c to return FA_ALTNAME instead of FA_CREATE when marked
%config(noreplace) in lib/rpmfi.c rpmfiDeci
On 30.05.2015 06:22, Jeffrey Johnson wrote:
The alternative scenario is equally plausible:
Sysadmin is trying to install software manually, lacks expertise in
configuring. Eventually\
the sysadmin attempts install from rpm packages, mis-configuration is
overwritten,
and everything Just Work. W
On 30.05.2015 06:22, Jeffrey Johnson wrote:
(aside)
You do realize that RPM5 embeds libgit2 sufficiently well to perform
a commit that git(1) understands? Discusssing Newer! Better! Bestest!
%config handling, with (.rpmnew/.rpmorig/.rpmsave) handling is
so so so last century ...
no
but i use et
On May 29, 2015, at 3:25 PM, Elan Ruusamäe wrote:
> On 29.05.2015 17:43, Jeffrey Johnson wrote:
>> I won't make the change in RPM upstream because I believe it's
>> more important to have consistent %config handling than it is to
>> preserve unpackaged configuration files on upgrade when the
>> n
On 29.05.2015 17:43, Jeffrey Johnson wrote:
I won't make the change in RPM upstream because I believe it's
more important to have consistent %config handling than it is to
preserve unpackaged configuration files on upgrade when the
new (but not the old) package has file content (which almost neve
On May 29, 2015, at 4:28 AM, Elan Ruusamäe wrote:
> On 29.05.2015 00:13, Jeffrey Johnson wrote:
...
>> Was this behavior seen in a multiple package upgrade that you have snipped
>> out?
> nop. this was 1 package upgrade:
>
OK thanks for -vv output.
> # rpm -q nagios-nrpe
> nagios-nrpe-2.15-1.
On 29.05.2015 00:13, Jeffrey Johnson wrote:
My guess (similar to your previous claim of "overwritten") is that package order
ended up as erase-before-install as part of a multiple package upgrade.
yes, pld rpm 4.5 got some (your) patch there eventually.
Was this behavior seen in a multiple pack
On May 25, 2015, at 9:01 AM, Elan Ruusamäe wrote:
> again rpm is ovewriting existing files, not creating them as .rpmnew when the
> file is "new" in the package itself.
>
Claiming "overwriting" is premature (see below).
> imho this got solved at least in 4.5...
>
Comparisons to rpm-4.x beha
12 matches
Mail list logo
