[Rpm-maint] Removing repackage and (auto)rollback?
pmatilai at laiskiainen.org
Tue Feb 19 16:45:41 UTC 2008
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
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
> 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 -
More information about the Rpm-maint