Need a referee - BUG or RFE?
Can I get a vote on whether the snippet below from bug 10226 represents a feature request or a bug? Being the bug Nazi is a thankless job. :) Mark http://trac.macosforge.org/projects/macports/ticket/10226 -------------- (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. ----------------------
On 04.10.2006, at 07:24, Mark Duling wrote:
Can I get a vote on whether the snippet below from bug 10226 represents a feature request or a bug? Being the bug Nazi is a thankless job. :)
[The port database is sometimes left in an inconsistent state when the port command is aborted] IMHO: It's a bug, plain and simple. It has hit me before. It's not even documented anywhere that I can see. If you think we cannot fix it at the moment, we should at least trap all signals to show that it's our "intention" not to have port interrupted except by kill -9. Which would make it an obvious bug: Not being supposed to interrupt a process that might be running for 24 hours on end is a pain. That said, you can abort port in relative safety while it's fetching files; and you can interrupt it while it's unpacking or configuring things provided that you "port clean" immediately afterwards. Killing it while it's building is more dangerous because you never know if the signal arrives in time. ;) So a slightly more useful signal handler might flag "abort requested", with port stopping once it's safe to do so. Regards, Marc
--On 3 October 2006 22:24:19 -0700 Mark Duling <mark.duling@biola.edu> wrote:
Can I get a vote on whether the snippet below from bug 10226 represents a feature request or a bug? Being the bug Nazi is a thankless job. :)
Mark
It looks like a bug to me. I'd expect the MacPorts database to accurately reflect the changes that MacPorts has made to its environment.
http://trac.macosforge.org/projects/macports/ticket/10226 -------------- (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. ----------------------
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
-- Ian Eiloart IT Services, University of Sussex
On Oct 4, 2006, at 1:24 AM, Mark Duling wrote:
Can I get a vote on whether the snippet below from bug 10226 represents a feature request or a bug? Being the bug Nazi is a thankless job. :)
It's probably a bug. But it might not be as serious as the reporter says. Port info, the portIndex and the portfile's gnupg version number don't have anything to do with what version port thinks is installed. Also, it's possible that gnupg 1.4.5 was installed, but not activated (but there's not enough information in the bug report to determine this). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
It's probably a bug.
Thanks for the input everyone. I updated the ticket summary. If anybody has a better idea for the summary either change it or let me know. http://trac.macosforge.org/projects/macports/ticket/10226 Mark
participants (4)
-
Daniel J. Luke
-
Ian Eiloart
-
Marc André Selig
-
Mark Duling