Changes between Version 55 and Version 56 of PortfileRecipes

Timestamp:

Mar 6, 2013, 12:54:28 AM (11 years ago)

Author:

neverpanic (Clemens Lang)

Comment:

use more block code listings

PortfileRecipes

@@ -468 +468 @@
 * `registry_active` takes a port name as argument and returns a list of matching active ports. It is defined in source:trunk/base/src/macports1.0/macports.tcl as an alias of `registry::active`. While it might seem odd that it returns a list, it makes sense if you know that it will return a list of all active ports when called with an empty argument.
 * `registry::active` is defined in source:trunk/base/src/registry2.0/registry.tcl. The only relevant case (since we're all using the SQLite registry by now) forwards the call to `receipt_sqlite::active` (in source:trunk/base/src/registry2.0/receipt_sqlite.tcl), where it queries all matching ports using `registry::entry installed $name` (which is defined as `entry_installed` in source:trunk/base/src/registry2.0/entry.c, if you want to dig in). It then converts the returned list of registry entry objects to a Tcl list using the following line of code (which is the reason why we've been digging through the code):
-  {{{
+  {{{#!tcl
 foreach port $ports {
     lappend rlist [list [$port name] [$port version] [$port revision] [$port variants] [string equal [$port state] "installed"] [$port epoch]]
@@ -480 +480 @@
  - Index 4: 1, if the port is installed, 0 otherwise
  - Index 5: port epoch
-* From this journey into MacPorts internals, we know that `registry_active` will return a list, but in our case it will always only contain one element. We can strip the outer list using `[lindex $returnval_of_registry_active 0]`.
+* From this journey into MacPorts internals, we know that `registry_active` will return a list, but in our case it will always only contain one element. We can strip the outer list using
+  {{{#!tcl
+lindex $returnval_of_registry_active 0
+}}}
 * Because `registry_active` will raise an error if the port requested is not active, we need to wrap it in a catch statement. If catch returns 0 (i.e., no error occured), we know the port in question is active.
 * In the example above, we retrieve the version of `kerberos5` (from index 1) and check using `vercmp` whether it is lower than 1.11. If it is, we need to deactivate the `kerberos5` port. Your case might differ here, because you might have to check revision and/or epoch.
-* To deactivate the conflicting port, we can use `registry_deactivate_composite` (and you can probably guess that this is an alias, too, and where you can find it). `registry_deactivate_composite $name "" $options` is a shorthand for `registry_deactivate $name "" "" 0 $options` and will deactivate the port indicated by `$name`. The second argument is a version number, which we can leave empty in this case. If we would normally try to deactivate `kerberos5` it might fail, because other ports might still depend on `kerberos5` being present. Since we know that it will be reinstalled soon anyway, we can just force deactivation without paying respect to the dependent ports (which we do by passing `[list ports_nodepcheck 1]` as `$options` argument.
+* To deactivate the conflicting port, we can use `registry_deactivate_composite` (and you can probably guess that this is an alias, too, and where you can find it).
+  {{{#!tcl
+registry_deactivate_composite $name "" $options
+}}}
+  is a shorthand for
+  {{{#!tcl
+registry_deactivate $name "" "" 0 $options
+}}}
+  and will deactivate the port indicated by `$name`. The second argument is a version number, which we can leave empty in this case. If we would normally try to deactivate `kerberos5` it might fail, because other ports might still depend on `kerberos5` being present. Since we know that it will be reinstalled soon anyway, we can just force deactivation without paying respect to the dependent ports (which we do by passing `[list ports_nodepcheck 1]` as `$options` argument.