rpm -Uhv --oldpackage loses configs

[Jeffrey Johnson]

> On Jun 7, 2016, at 10:57 PM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
> 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
> 

OK, I’ll bite: you quote James Antill from 8 years ago … what are you trying to say? Please …

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

So you seem to not like “FS snapshots” … Good, I think FS snapshots have little to
do with —rollback too, we may possibly agree. FS snapshots have a usage case,
but not with —rollback for package management.

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

Obsolesence? Hardly … there are some serious flaws in RPM in need of
repair 20+ years later … including %config handling, the start of this thread.

(aside)
I do have some serious credentials having 18+ years experience with RPM,
and also having implemented 2-3 —rollback schemes in RPM, mostly useless
for other reasons. You could (but apparently the EU funded Mancoosi task force 3 on transactional
package management mail archives are no longer available, oh well) read the history of what has
transpired this century, certainly more details since James Antill posted in 2008, if really interested …

… but go ahead and claim vaporware or accuse me of keeping my ideas “secret” (or worse, not
able to backup my claims with an implementation) if you insist.

All I meant to suggest is that the PLD devel list is _NOT_ the pace to discuss RPM package management
issues (including repackaging, and —rollback) seriously.

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

What are you trying to say here? Do you like/want repackaging or not? I did successfully implement
repackaging (what is currently used by PLD) while @redhat in like 2003 or so.

I’m happy you like what I implemented, but damfino what you wish changed.

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

Um, a yum-history citation, and from 2010— which depends on what is called a “yumdb” —
is mostly useless, perhaps more useless than FS snapshots that you seem to dislike.

JMHO, YMMV. We can explore details as you wish ...

The very serious flaw(s) with a yumdb are:

	1) any value (like a nominal ~128b string containing package NEVRA) uses an
	entire (usually 4Kb) block on a FS. That is 4096 - 128 = 3968b of wasted disk space.

	2) there is no means to truncate yumdb file system usage, a yumdb is forever (well, you
	can just nuke the entire FS tree whenever you want to regain FS space for other uses)

I can/will enumerate several additional flaws if absolutely necessary. We seem to agree that
yum-history is not appropriate for PLD (and more generally, rather a waste of disk space).

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

You’ll have to remind me of what I wrote, I have written lots about RPM over the years …

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

You need to study before responding: Poky/Yocto install images are produced
by cross-compilation on standard *x86 blade hardware, nothing whatsoever
to do with “embedded”, and (perhaps) very little to do with “repackaging”.

I mentioned P/Y largely because of what is called a “solvedb”, which is
little more than an rpmdb with a URL pointer to the original (or copy) *.rpm package,
which solves the problem of removed/erased files that repackaging will never
be able to solve correctly.

Meanwhile, <rpm-devel at rpm5.org>, not <pld-devel-en at lists.pld-linux.org>,
is the proper forum for discussion of RPM. That is all that I said.

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

Once you remove “old ones” (presumably ones == packages), you risk a loss of
referential integrity. We might (but unclear) even agree on this point.

I know of at least 3 linux distros (including @redhat.com) that have independently
discovered that you MUST keep a permanent record of all published packages in
order to do “upgrades” … or possibly “downgrades” … reliably.

(aside)
Please don’t take my comments personally: I’ll be happy to discuss better RPM
implementations as you wish in an appropriate forum related to RPM, not PLD.

73 de Jeff