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: > > > package dpkg > > > tags 432893 + patch > > > kthxbye > > > > > > 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. > > > > 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.
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. 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. > > 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. > > 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. > > 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. > > > 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? > > Well, we don't have many choices. Unpacked is the only case I can see > where that would be a problem. And in that case, I think that it does > no harm to either mark it as failed-config or leave it unpacked, since > the cases are almost identical: it will still have to be configured. Does it (allow to) call the prerm in Config-files or Half-installed state? I think in Config-files state, you probably want to keep it, and if my memory is good it doesn't allow you to remove the package in Half-installed state. If that's the case, the state = abort_remove_ok?prev_state:failed_config; looks right to me. We should probably open a bug against policy to make this more clear. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
