rpm 5.x in Th

[Jeffrey Johnson]

On Sep 22, 2012, at 4:00 PM, Łukasz Chrustek <lukasz at chrustek.net> wrote:

> Witam,
> 
> 
>> On Sep 22, 2012, at 12:59 PM, Łukasz Chrustek <lukasz at chrustek.net> wrote:
> 
>>> 
>>> I have problem with rollback option in latest rpm:
>>> 
>>> # export LANG=en_EN.UTF-8;rpm -Uvh --rollback '20 minutes ago'
>>> Rollback goal:  Sat Sep 22 18:35:29 2012 (0x505de8d1)
>>> BDB2053 Freeing read locks for locker 0xf1: 13697/3061184384
>>> BDB2053 Freeing read locks for locker 0xf2: 13697/3061184384
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> BDB2017 Freeing mutex for process: 13697/0
>>> rpm: rpmdb.c:2742: rpmmiInit: Assertion `keylen == sizeof(he->p.ui32p[0])' failed.
>>> zsh: abort      rpm -Uvh --rollback '20 minutes ago'
>>> 
> 
>> Are you actually using --rollback? If so, you are the
>> only person on the planet using --rollback.
> 
> Well,  so  remove this option from rpm if it isn't usable. What for is
> it  now  ?  I  think  it is/was nice, fast and proper way to return to
> working  set  of  last updated set of packagaes. For what is repackage
> (from where I took the old version in this case) ?
> 

The --rollback option needs to be reconnected to
a beter mechanism rather than removed.

Repackaging works same as always. Set
    # If non-zero, all erasures will be automagically repackaged.
    %_repackage_all_erasures 1 

>> There are no plans to support the previous --rollback
>> mechanism @rpm5.org: WYSIWYG (and the entire mechanism
>> is too cumbersome to use, you can find my analysis
>> on some Mancoosi WP3 mailing list a couple years ago
>> if so inclined).
> 
> OK.  Do  You  have/see  some  other  way  to  manage  transactions and
> repackeged rpms ?
> 

Nope. Everyone is too busy telling me how important
--rollback is/was, too busy to actually use.

The expectation has always been of partial rollbacks,
as in upgrading everything but some buggy package
and perhaps its dependents. The "partial" is plain
and simply _NOT_ how any serious transactional logging
system is architected.

>> Much better is/was possible/planned in rpm-5.3.x. Sadly
>> the Mancoosi project decided to "fix" apt instead of rpm
>> and --rollback efforts with TPPM in RPM were never finished.
> 
> And there is no plans for finish them ?
> 

Noone is asking for --ropllback: why should I bother? I
certainly know what is/was intended and implemented.

Adding logs for all file system content ends up
saving (at least) 3 copies of all content:
	1) the copy installed on the file system
	2) the initial copy when first installed
	3) the final copy when last erased
which just leads to complaints of Bloat! Bloat! Bloat!
and manual erasures that destroy log continuity.

The whole idea of ACID behavior is based on duplication
in logs that _MUSGT_ be preserved in order to repair
any damage.

Since most "systems" (or configurations) just have a single
root partition, useful ACID behavior also expects off-line
backups and sysadmin awareness/maintenance.

In reality, a hard disk failure tends to destroy not
only rpmdb/content, but also the logs from which the
stateful content might be recreated.

rpm-5.3.x includes a MongoDB client, which could/would
eliminate the need for saving state on clients where
a hard disk failure also loses logs, but so far, no
distro is willing to host a MongoDB server.

I have hosted my own mongodb servers, but there is literally
zero interest, and I'm tired of wasting time if
noone is currently interested.

>> These days BTRS! BTRFS! BTRFS! snapshot management
>> (which isn't --rollback transactional package management) is likely
>> what most users want/need/expect. Inserting the necessary
>> BTRFS ioctls is a very simple implementation waiting
>> for BTRFS to become usefully/stably deployed in linux.
> 
> OK.  I  don't know what to say here. I don't know why rollback need to
> be  connected  with  any  file  system,  for  me  it  is  some kind of
> overreacting :P.
> 

Until client state is kept remotely -- immune to hard
drive failures -- there is only the local file system
that can be used to preserve the state changes over time.

That should be obvious; the naive simplicity of a
BTRFS (or other file system) "snapshot" that Just Works
with no other application changes than performing a before
snapshot and commit/discard based on success/failure 
should also be obvious.

What is less obvious is the complexity introduced by
mount points, and that snapshots include all changes,
not just package management changes.

hth

73 de Jeff
> -- 
> Regards,
> brushek
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en