BUG: port command can't be interrupted cleanly - creates database inconsistency

[yaseppochi (Stephen J. Turnbull)]

Attempting to upgrade gnupg from 1.4.4_0 to 1.4.5_0 hangs (reported separately).

After waiting 5 min, I interrupted the "port -v upgrade gnupg" process. This left my ports in the following peculiar state:

port info gnupg claims that gnupg is at 1.4.5. The PortIndex file claims that gnupg is at 1.4.5. The Portfile claims that gnupg is at 1.4.5. port outdated doesn't report gnupg as outdated. gnupg 1.4.4_0 has been deactivated, quietly leaving me without gpg.

This is really evil, especially considering that the deactivation normally takes place just before activating the new version. By scrolling back to the beginning, I can see that the deactivation took place, but if one habitually runs with port -d, or immediately reruns the upgrade with -d without looking closely at the output, he'll probably miss the fact that gnupg was deactivated.

port built 1 Aug 2006 00:07 JST from freshly updated CVS.

[markd@…]

Most programs don't guarantee behavior after an abnormal cancellation. If you could recommend specific changes to be made this could be an RFE rather than a bug.

[markd@…]

I think we can close this since since the cause is filed in ticket 10227. There is no clear answer to the effect, if there are sugestions it should be done as an RFE.

[yaseppochi (Stephen J. Turnbull)]

(1) This is a bug in port, not in gnupg. Any time a user feels the need to interrupt port, she's at risk of this bug. It is in no way restricted to gnupg.

(2) It is a BUG, not an enhancement request. port is not "most programs", it is a database management system. Any action that changes the database should be encapsulated in a transaction, and it should be rolled back on anything but normal completion of the task.

If this facility can't be added to port, then at least trap all aborts and all error terminations (at least the deactivation of random prerequisities can occur without an abort), and report "DANGER! DANGER! DANGER! MacPorts is possibly corrupt! Be prepared for complete loss of functionality in random programs!"

I don't know enough about port to be able to make concrete suggestions, but surely there's enough information available for port to make more specific warnings, and perhaps do some error recovery, even in the case of the user pushing the panic button.

[markd@…]

What is meant by the term BUG is defined by our community, not you and not me. I didn't regard severity of consequences or desireability to have anything to do with whether something was considered an RFE or BUG, but I suppose I could be wrong. Since these terms are defined by our community, I'll put the question to them on the list. I'll abide by the consensus if you will, fair enough? Getting a request in the wrong slot just guarantees it will get no attention. I'm trying to help. ;-)

[wyuenho (Jimmy Yuen Ho Wong)]

The definition of a bug is a philosophical question but I think I can try. The most commonly accepted definition for a software bug, as defined by Wikipedia is

"A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result."

The keyword here is "intention", a bug is a bug only if the result of an action doesn't not reflect the original intention.

In this case, I highly doubt the original Macports developers intented to leave the port system states corrupted by leaving the default signal handler to handler interrupts. If I were a judge, I'd rule this as a serious bug. After so many years since this project first started, it surprises me that port still does not have a transaction mechanism or even in a future development plan. Granted, implementing a simple transaction mechanism in ports involves many changes and feature additions, but that still doesn't change the fact that this is a ligitimate bug. The solution to a bug does not define what a bug is, the intention and output do. I recommend bumping this bug to high priority so a transaction system can be within sight.

[markd@…]

The community says it's a bug. I changed the summary to something I think gets the point across a little better. If not, let me know.

[vinc17@…]

It depends how the port command was terminated. Signals INT (sent by Ctrl-C), TERM (sent e.g. at shutdown) and HUP should be regarded as normal termination. Therefore port should either clean up (quickly) before exiting or should provide a clean-up command (as Subversion and some other DB do, for instance). But I know that there's no way to clean up easily after a SIGINT... In any case, it is better to have a simple recovery feature, whatever happens (imagine if you would always lose all your hard disk data after an unexpected power down).

[yaseppochi (Stephen J. Turnbull)]

I think the new summary is accurate.

Regarding the definition of "bug", I certainly agree that the community should define it. I just didn't think there would be a question about whether failure of database integrity should be considered a bug, when put in those terms.

[markd@…]

No problem. I do agree it is a bug. At the time I just misunderstood the problem you were describing. And when you described it in more detail I hadn't got completely over my confusion so my mind focused in on certain aspects of possible solutions you mentioned in terms of added features, some of which I think would be features. But now I understand the problem better and I agree that the main issue is a bug. I like to get as clear summary lines as possible and sometimes they evolve over time as other people encounter them. Hopefully it will get swatted soon. Thanks for your attention to this.

[jmpalacios (Juan Manuel Palacios)]

I have to admit I don't fully understand what was the consequence of cancelling the upgrade in this case. Quoting the original report:

"port info gnupg claims that gnupg is at 1.4.5. The PortIndex file claims that gnupg is at 1.4.5. The Portfile claims that gnupg is at 1.4.5."

So far everything is consistent, info reads from the index and the index takes its information from what's listed in the Portfile. Carrying on:

"port outdated doesn't report gnupg as outdated. gnupg 1.4.4_0 has been deactivated, quietly leaving me without gpg."

If the final result and the cause for the bug report is that gnupg is left deactivated, maybe an argument that it should be reactivated before aborting could be made, but that's by no means a database inconsistency. Stephen, what happens if you try to reactivate the old gnupg manually after cancelling the upgrade?

Other than that, I'm not sure whether or not 'port outdated" looks at deactivated ports to do its magic, but in case it doesn't an argument that it should could easily be made too. But then again, that's another bug and/or feature request.

Setting this ticket to "Needs developer review" until we have more information on what's really at fault here, if anything.

-jmpp

[ryandesign (Ryan Carsten Schmidt)]

Adding reporter to Cc.

[jmpalacios (Juan Manuel Palacios)]

Milestone Needs developer review deleted

[tobypeterson]

Milestone MacPorts base bugs deleted

[blb@…]

Perhaps if port were to trap Ctrl-C and have certain actions based on which phase was active at the time:

• during anything up to and including destroot, just stop since it can be safely resumed from where it left off
• during install, remove what it installed in ${prefix}/var/macports/software
• during activate, ignore the signal until it completes activation, perhaps with a message
• during deactivate, either ignore or go back to activate
• during uninstall, since this has probably already begun deleting there's probably no choice but to let it finish

[schneider.pj@…]

Cc Me!

[guillaumesalagnac]

CC me!

[nerdling (Jeremy Lavergne)]

Cc Me!

[gardnermj@…]

Cc Me!

[gardnermj@…]

This just bit me (CTRL-C during an uninstall corrupted my ports database somehow, forcing me to reinstall MacPorts from scratch).

How do apt, yum & co. handle this problem?

[cooljeanius (Eric Gallager)]

Cc Me!

[frozencemetery (Robbie Harwood)]

Cc Me!

[mf2k (Frank Schima)]

Should be fixed in current trunk.