[MacPorts] PortfileRecipes modified

MacPorts noreply at macports.org
Tue Mar 5 16:19:10 PST 2013


Page "PortfileRecipes" was changed by cal at macports.org
Diff URL: <https://trac.macports.org/wiki/PortfileRecipes?action=diff&version=49>
Revision 49
Comment: start documenting the deactivate hack
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: PortfileRecipes
=========================================================================
--- PortfileRecipes (version: 48)
+++ PortfileRecipes (version: 49)
@@ -446,3 +446,21 @@
 * 'GPLConflict' should be added if the license conflicts with the GPL (and its variants like CeCILL and the AGPL) and is not in the list of licenses known to do so below.
 * 'Noncommercial' means a license that prohibits commercial use.
 * Public domain code, while technically not having or needing a license, should list the license as 'public-domain'.
+
+== Using the "deactivate hack" == #deactivatehack
+Using the so-called deactivate hack becomes necessary when a file that used to be provided by port A is going to be provided by port B from now on and we need a seamless update path. Without the deactivate hack the activation phase of port B would fail because one of the files it tries to install is already there. The deactivate hack works around this problem, by deactivating A if it is active. It is often combined with a check for a specific version of A. An example might clear this up:
+
+Let's say the `kerberos5` port used to install the file `${prefix}/bin/compile_et`, but we're trying to move this part to a library called `libcomerr`. Since the `kerberos5` port will still need `compile_et` to build, it will add a dependency on `libcomerr`. This will cause MacPorts to install `libcomerr` before upgrading `kerberos5`. When MacPorts tries to activate `libcomerr`, the old version of `kerberos5` is still active and the conflicting file is still installed. Usually, MacPorts would bail out at this point and require the user to solve this problem manually. However, since this would affect all users that had `kerberos5` installed, this is undesirable.
+
+In this very case, we know `kerberos5` stopped providing `compile_et` in version 1.11. We will add the deactivate hack to `libcomerr`, where it will check whether any `kerberos5` <= 1.11 port is active, and if there is, it will deactivate it before activating `libcomerr`. After activating `libcomerr`, MacPorts will then happily continue with the upgrade and install the new (and non-conflicting) version of `kerberos5`. The following block is taken from the `libcomerr` Portfile:
+
+{{{#!tcl
+# both kerberos5 and e2fsprogs previsouly conflicted because they installed files now provided by libcomerr
+if {![catch {set installed [lindex [registry_active kerberos5] 0]}]} {
+    set krb_version [lindex $installed 1]
+    if {[vercmp $krb_version 1.11] < 0} {
+        # kerberos5 used to install some files now provided by libcomerr in versions < 1.11
+        registry_deactivate_composite kerberos5 "" [list ports_nodepcheck 1]
+    }
+}
+}}}
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://trac.macports.org/wiki/PortfileRecipes>
MacPorts <http://www.macports.org/>
Ports system for OS X

This is an automated message. Someone added your email address to be
notified of changes on 'PortfileRecipes' page.
If it was not you, please report to .


More information about the macports-changes mailing list