rpm -Uhv --oldpackage loses configs

[Jeffrey Johnson]

> On Jun 7, 2016, at 1:58 PM, Elan Ruusamäe <glen at delfi.ee> wrote:
> 
> 
>> Meanwhile abandoning %config renaming (and doing a git check-in with RPM+LIBGIT2),
>> is likely the best forward-looking solution.
> pld will not sign up to this. %config handling needs to be fixed.

Then PLD has its solution …
	Patches cheerfully accepted at <rpm-devel at rpm5.org>

>> There are also better solutions than /var/spool/repackage that can be attempted these
>> days.
> why are you sure it's repackage problem if you can't even understand why it behaves like it does.
> i've seen rpm losing configs ever other corner. this was just easily reproducible use case.

I’m not sure of anything I cannot reproduce by “make test” when developing RPM, there
are far too many issues that have to be controlled for.

Note that —downgrade (even as a popt alias for —old package) has never been supported
(or tested) by rpm. Sure you can add —oldpackage (or any other disabler) as you wish,
but you are also responsible for the effects of, say, adding —replace files (which will clobber
%config every single time, exactly by design).

I cannot use a docker environment under “make test” while developing is all that I intended to say. 

And to support —downgrade meaningfully, I need a “reproducible” test case with toy packages.

Meanwhile, for less effort, I believe that doing RPM+LIBGIT2 is far more beneficial than
trying to resurrect and modernize %config renaming: there are too many problems with
renaming and manual intervention to “fix” an installation after running rpm (as you have
reported many many times).

> [*1]: may need beta signup, i'm not using win/mac myself
> 
> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org <mailto:pld-devel-en at lists.pld-linux.org>
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en <http://lists.pld-linux.org/mailman/listinfo/pld-devel-en>