Re: [31791] trunk/dports/devel
Please do not do this! This will end up in a dead-lock!!! "bzr activate" will wait for "bazaar activate" to finish, which will never happen (as "bazaar install" is waiting for "bzr activate"). Regards, -Markus On 07.12.2007, at 17:05, ram@macports.org wrote:
Revision 31791 Author ram@macports.org Date 2007-12-07 08:05:11 -0800 (Fri, 07 Dec 2007) Log Message rename bazaar-ng port to bzr, automatically upgrade to this new port Modified Paths trunk/dports/devel/bazaar-ng/Portfile trunk/dports/devel/bzr/Portfile Added Paths trunk/dports/devel/bzr/ Removed Paths trunk/dports/devel/bazaar-ng/files/ Diff Modified: trunk/dports/devel/bazaar-ng/Portfile (31790 => 31791) --- trunk/dports/devel/bazaar-ng/Portfile 2007-12-07 15:15:18 UTC (rev 31790) +++ trunk/dports/devel/bazaar-ng/Portfile 2007-12-07 16:05:11 UTC (rev 31791) @@ -1,49 +1,37 @@ # $Id$ PortSystem 1.0 - PortGroup python25 1.0 name bazaar-ng version 0.92 -revision 3 +revision 4 categories devel python platforms darwin maintainers ram openmaintainer -description The next-generation distributed version control system -long_description Bazaar is an open source distributed version control \ - system that is powerful, friendly, and scalable. It manages trees of \ - files and subdirectories, In particular, it records revisions of trees, \ - representing their state at a particular point in time, and information \ - about those revisions and their relationships. Recording and retrieving \ - tree revisions is useful in several ways if you are writing software or \ - documents or doing similar creative work. +description This port has been made obsolete by the bzr port +long_description ${description} homepage http://bazaar-vcs.org/ - master_sites ${homepage}releases/src/ -distname bzr-${version} - checksums md5 f91e760d646660f0f790066ff0526b38 \ - sha1 51901b0c467e30dab9e51b990bb491752460d680 \ - rmd160 f7a6c24944be50c830c25376bfaf0d2b8c56ae56 - -patchfiles patch- setup.py.diff \ - patch-bzr.dev-r2966.diff \ - patch-bzr.dev- r2975.diff \ - -depends_lib-append port:py25-paramiko \ - port:py25- crypto \ - port:py25-hashlib \ - port:py25-zlib \ - port:py25-bz2 - -test.run yes -test.cmd make -test.target check - -post-destroot { - xinstall -m 644 -W ${worksrcpath} INSTALL NEWS README TODO \ - $ {destroot}${prefix}/share/doc/${name} +fetch { + ui_msg "" + ui_msg "Port bazaar-ng has been superseeded by port bzr" + ui_msg "bzr will be installed after removing bazaar-ng" + ui_msg "" } +checksum {} +configure {} +build {} +destroot {} +archive {} +install { + ui_msg "Removing bazaar-ng" + system "port -f uninstall bazaar-ng" + ui_msg "Installing bzr" + system "port install bzr" + ui_msg "Port bzr has been installed" +} +activate {} universal_variant no Copied: trunk/dports/devel/bzr (from rev 31790, trunk/dports/devel/ bazaar-ng) Modified: trunk/dports/devel/bzr/Portfile (31790 => 31791) --- trunk/dports/devel/bazaar-ng/Portfile 2007-12-07 15:15:18 UTC (rev 31790) +++ trunk/dports/devel/bzr/Portfile 2007-12-07 16:05:11 UTC (rev 31791) @@ -3,9 +3,8 @@ PortSystem 1.0 PortGroup python25 1.0 - name bazaar-ng +name bzr version 0.92 -revision 3 categories devel python platforms darwin maintainers ram openmaintainer @@ -21,7 +20,6 @@ homepage http://bazaar-vcs.org/ master_sites ${homepage}releases/src/ -distname bzr-${version} checksums md5 f91e760d646660f0f790066ff0526b38 \ sha1 51901b0c467e30dab9e51b990bb491752460d680 \ _______________________________________________ macports-changes mailing list macports-changes@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-changes
--- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/
On Dec 7, 2007 1:18 PM, Weissmann Markus <mww@macports.org> wrote:
Please do not do this! This will end up in a dead-lock!!!
"bzr activate" will wait for "bazaar activate" to finish, which will never happen (as "bazaar install" is waiting for "bzr activate").
I did it this way as this is the approach the abiword2 port uses to change to the abiword-x11 port. So how can I achieve this and avoid the dead-lock? Cheers Adam
On Dec 7, 2007, at 12:44, Adam Mercer wrote:
On Dec 7, 2007 1:18 PM, Weissmann Markus wrote:
Please do not do this! This will end up in a dead-lock!!!
"bzr activate" will wait for "bazaar activate" to finish, which will never happen (as "bazaar install" is waiting for "bzr activate").
I did it this way as this is the approach the abiword2 port uses to change to the abiword-x11 port. So how can I achieve this and avoid the dead-lock?
I haven't looked at your changes and I don't know if the deadlock Markus describes will occur. But I have suggested a couple times that we should have a portfile keyword like "superseded_by" which can be used to indicate that a given port name is obsolete. Behavior of this keyword would be that anyone who has the port installed and uses port upgrade sees this port as needing to be upgraded. Anyone who attempts to upgrade this port gets a message that they need to uninstall this port and install this other port. Once those steps are implemented and released, we could look into more elegant solutions including MacPorts automatically uninstalling the old port and installing the new one with the same variants or something, but I don't think that's essential.
On Dec 7, 2007, at 4:44 PM, Ryan Schmidt wrote:
I haven't looked at your changes and I don't know if the deadlock Markus describes will occur. But I have suggested a couple times that we should have a portfile keyword like "superseded_by" which can be used to indicate that a given port name is obsolete. Behavior of this keyword would be that anyone who has the port installed and uses port upgrade sees this port as needing to be upgraded. Anyone who attempts to upgrade this port gets a message that they need to uninstall this port and install this other port.
You can achieve this now with a pre-fetch ui_msg (and bumping the revision of the port that you want to remove).
Once those steps are implemented and released, we could look into more elegant solutions including MacPorts automatically uninstalling the old port and installing the new one with the same variants or something, but I don't think that's essential.
That might be an interesting project for someone, but given that this doesn't happen that often, I don't think any of the people who normally develop stuff for base are working on it. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 07.12.2007, at 23:38, Daniel J. Luke wrote:
On Dec 7, 2007, at 4:44 PM, Ryan Schmidt wrote:
I haven't looked at your changes and I don't know if the deadlock Markus describes will occur. But I have suggested a couple times that we should have a portfile keyword like "superseded_by" which can be used to indicate that a given port name is obsolete. Behavior of this keyword would be that anyone who has the port installed and uses port upgrade sees this port as needing to be upgraded. Anyone who attempts to upgrade this port gets a message that they need to uninstall this port and install this other port.
You can achieve this now with a pre-fetch ui_msg (and bumping the revision of the port that you want to remove).
Once those steps are implemented and released, we could look into more elegant solutions including MacPorts automatically uninstalling the old port and installing the new one with the same variants or something, but I don't think that's essential.
That might be an interesting project for someone, but given that this doesn't happen that often, I don't think any of the people who normally develop stuff for base are working on it.
Yes. Thats exactly what I wanted to say. And also perhaps that yes, the deadlock will occur. Regards, -Markus --- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/
participants (4)
-
Adam Mercer
-
Daniel J. Luke
-
Ryan Schmidt
-
Weissmann Markus