rpm -Uhv --oldpackage loses configs

[Tomasz Pala]

On Tue, Jun 07, 2016 at 14:29:24 -0400, Jeffrey Johnson wrote:

>>> There are also better solutions than /var/spool/repackage that can be attempted these
>>> days.
>> 
>> What are they? Filesystem-level snapshots are not suitable when you need
>> to revert anything older than a few hours maybe (can anyone afford
>> restoring 2 weeks old state and replaying every other change that was
>> made meanwhile?), so what else?
>> 
>> And if not for --rollback, repackages are great for cherry-picking
>> single package do downgrade.

http://lists.rpm.org/pipermail/rpm-maint/2008-February/001911.html

FS-level snapshots are shortest way to 'reboot to upgrade' insanity.

> <pld-devel@ ???> is not the place for RPM development discussions.

It's you who are doing some obsolescence suggestions, just don't do that
if you have nothing clear as a replacement or going to make it secret.

> This thread is/was diagnosing a problem and devising a solution, not otherwise.

Different approach to entire repackage (that YOU suggested) is also a solution.

The only alternative I know:
https://www.redhat.com/archives/rhelv6-beta-list/2010-June/msg00056.html
yum-history, is not suitable for PLD due to rolling releases - package I
had might be not available for download anymore. yum-plugin-fs-snapshot
is a no-go on any non-desktop or non-singleuser machine. That leaves us
with not a single 'better solutions these days'.

I remember you wrote about libgit a few years ago, but that might handle
%config problems only, but not restoring packages to some previous
(working) state.

> See Poky/Yocto image construction for what RPM5 can already do when
> used intelligently.

I doubt embedded platform uses rpm5 to solve issues like "there is a
problem with foo using libbar we have upgraded last week, need to
restore previous versions and do some more tests on separate/clean
environment". So unless you are willing to share the mysterious features
that might be used instead repackages, I'm not going to waste my time
digging in system build with different principles in mind and for entirely
different purpose than PLD. That's great, if rpm5 solves their problems
- can it solve ours? If so, just tell us how. No need for elaborates.

OK, I know one solution: fetching rpms via permanent-store proxy like
wwwoffle and keeping those rpms forever, as there is no way to implement
"keep THAT time since package was upgraded" policy. Repackages are
superior in two ways:
1. they are timestamped on upgrade, so one could remove old ones,
2. they retain current configuration within.

-- 
Tomasz Pala <gotar at pld-linux.org>