[Rpm-maint] Removing repackage and (auto)rollback?

[Panu Matilainen]

On Tue, 19 Feb 2008, James Olin Oden wrote:

> On Feb 19, 2008 3:45 AM, Panu Matilainen <pmatilai at redhat.com> wrote:
>>
>> Before anybody asks: I actually do think that ultimately rpm should be
>> able to support reliably rolling back transactions. It's just that the
>> current repackage+rollback combo fails to deliver it, as there's no way to
>> undo script actions.
>>
>> So... I'm considering axing the rollback and related code out of rpm, two
>> somewhat separate parts here:
>>
>> 1) Configurable repackaging of on-disk contents on erasure, manual
>> rollback from cli. While not terribly intrusive, it's in my view an
>> unsupportable feature because it fails to deliver reliable rollbacks and
>> cannot be fixed (because of the fundamental issue with scriptlets
>> doing things outside rpm's control).
>>
>> 2) Automatic rollback on failed transaction. Conceptually it's an awfully
>> nice feature, but as it's based on 1) which is unreliable to begin with...
>> To make matters worse, it's a feature that practically nobody uses, tests
>> or works on (James Oden who wrote the feature is in "the other rpm" camp
>> AFAIK) and which non-trivially complicates the transaction code for a
>> practically unused (and unusable) feature.
> You would be wrong.  I'm in no RPM camp at the moment.  If I was
> working on RPM I would have approached you guys about continued
> improvements.

Ok, apologies for wrong assumption then :)

> Honestly, though, rpm is the wrong place to do rollbacks.  You want to
> really have a reliable upgrade rollback you need to do it at the
> filesystem level.  Things are not quite there at present in linux to
> really support this but there much closer than they ever were.

Very much agreed. One would probably want some sort of integration for 
filesystem level rollback (mark beginning/end of transaction or such) but 
rpm wont be doing the heavy lifting in that case.

>> Me thinks it'd be more productive to investigate related items that could
>> be reliably implemented than attempt to "fix" what's fundamentally
>> broken...
>>
> The fix is not in rpm.  You will never be able to undo opaque
> scriptlets in a provably reliable way within the package manager.
> Its just not possible.

Indeed, and that's why I'd rather see the current implementation go - it's 
not possible to fix it. Of course one could just ban any scriptlets when 
rollbacks are configured but... :)

 	- Panu -