Hi, On Thu, 2007-09-13 at 01:18:14 +0200, Kurt Roeckx wrote: > On Wed, Sep 12, 2007 at 10:21:11PM +0000, brian m. carlson wrote: > > On Wed, Sep 12, 2007 at 11:27:27PM +0200, Kurt Roeckx wrote: > > > On Wed, Sep 12, 2007 at 08:59:37PM +0000, brian m. carlson wrote: > > > > Attached is a patch that *should* fix this bug. It simply restores > > > > the previous state of a package when a removal fails, instead of > > > > simply setting it to installed. Preliminary testing seems to confirm > > > > that this works. A changelog entry is also included.
Thanks for the patch! I'll push it later today. > > > Policy says: > > > If this fails, the package is in a "Failed-Config" state, or > > > else > > > it remains "Installed". > > > > Unfortunately, it's not very clear what "this" refers to: is it the > > entire series of scripts (step 1 in its entirety), or is it just the > > abort-remove call? I don't think it matters, since the result is the > > same. I think it's clear that the 'this' refers to the '<postinst> abort-remove' call. What seems confusing is what Kurt mentions in the next paragraphs... > You're right, this seems to be rather confusing. I think what it's > trying to say is if abort-remove fails, set to Failed-Config, else keep > the (Installed) state. It should probably also keep the other states. I agree that it should keep whatever previous state it had. > You could also argue that if abort-remove was succesful, it should be in > installed state, and that abort-remove in most cases should do the same > as configure. But as far as I understand things, abort-remove should > only undo what the prerm remove did, which isn't the same as configuring > it. Those are doing error unwinding, and should thus be trying to restore to the previous states. > > > Is there a reason that prerm failure doesn't always set the > > > Failed-Config state? dpkg has no idea which part of the prerm was > > > succesful and which not, it might have undone some part of the postinst > > > and then failed, and I think the Failed-Config makes most sense. Before calling '<prerm> remove' the code is already setting the package status as half configured. > > In the case that I tested, the abort-remove call was successful. I can > > add a test for the case when it is not and set the proper flags for that > > case as well. That's a trivial patch. Your first patch was fine already (the second one is not), the only thing I changed was moving the scope of oldpkgstatus. > > Knowing what policy says, my personal feeling in this case is: > > > > state = abort_remove_ok?prev_state:failed_config; > > > > A package obviously cannot "remain" anything when it wasn't that way in > > the first place. Right. > > > But I guess it should only do that if the original state was either > > > Installed or Failed-Config, and else keep the original state. > > > But I have no idea if it calls the prerm in the other states. For > > > instance, what should it do if called from Unpacked state? The call to '<prerm> remove' is only done if the package is installed or half configured. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
