Aug 252007
 

As reported by sem@, there is a problem with the display of master/slave relationships within FreshPorts. The relationship is stored in the ports table, with the master_port attribute being a pointer to the master port. This text field typically has values such as this:

freshports.org=#   SELECT DISTINCT(master_port)
freshports.org-#     FROM ports_active
freshports.org-# where master_port <> ''
freshports.org-# AND  master_port not like '/usr/home/dan/%'
freshports.org-# ORDER BY master_port
freshports.org-#    LIMIT 10;
       master_port
--------------------------
 archivers/unrar
 audio/aylet
 audio/festalon
 audio/festvox-us1-mbrola
 audio/gbsplay
 audio/gqmpeg
 audio/mbrola
 audio/napster
 audio/scrobbler
 audio/timidity++
(10 rows)

freshports.org=#

The query to find any slave ports of a given port is:

SELECT id          AS slave_port_id,
       name        AS slave_port_name,
       category_id AS slave_category_id,
       category    AS slave_category_name
  FROM ports_active
 WHERE master_port = 'sysutils/bacula-server'
ORDER BY slave_category_name, slave_port_name

Which, on my development server at home, for sysutils/bacula-server gives:

 slave_port_id | slave_port_name | slave_category_id | slave_category_name
---------------+-----------------+-------------------+---------------------
         13986 | bacula-client   |                20 | sysutils
(1 row)

The problem is: bacula-server is not listing bacula-client as a slave port. For that matter, in production, bacula-client isn’t listing bacula-server as its master port either. Strange. Very strange. It must be something very simple that has gone wrong here. This has worked in the past.

FreshPorts determines the MASTERPORT through make -V magic. Something like this:

[dan@ngaio:~/ports/sysutils/bacula-client] $ make -V MASTERPORT \
PORTSDIR=~/ports LOCALBASE=/nonexistentlocal X11BASE=/nonexistentx
sysutils/bacula-server
[dan@ngaio:~/ports/sysutils/bacula-client] $

This magic is accomplished with this patch:

$ less ~/bin/bsd.port.mk.master-slave-patch
--- bsd.port.mk 10 Jun 2004 07:30:19 -0000      1.491
+++ bsd.port.mk 22 Jun 2004 13:48:33 -0000
@@ -913,6 +913,16 @@

 MASTERDIR?=    ${.CURDIR}

+# Try to determine if we are a slave port.  These variables are used by
+# FreshPorts and portsmon, but not yet by the ports framework itself.
+.if ${MASTERDIR} != ${.CURDIR}
+IS_SLAVE_PORT?=        yes
+MASTERPORT?=   ${MASTERDIR:C/[^\/]+\/\.\.\///:C/[^\/]+\/\.\.\///:C/^.*\/([^\/]+\/[^\/]+)$/\1/}
+.else
+IS_SLAVE_PORT?=        no
+MASTERPORT?=
+.endif
+
 # If they exist, include Makefile.inc, then architecture/operating
 # system specific Makefiles, then local Makefile.local.


So something, somewhere has allowed this information to be wrong. A few days ago, I did notice that my cvsup crontab was going wrong and was not correctly patching the file after the upgrade. Perhaps that was it.

Running a few commits manually shows that is the problem. An unpatched Mk/*.

I’ll work on getting that fixed and then run a script to check for a master port for each port.

  2 Responses to “master / slave relationships”

  1. All should be fixed now.

  2. I recently learned that ports/Mk/bsd.port.mk contains code for MASTER_PORT, very similar to MASTERPORT in the patch above. This is great for FreshPorts. It simplifies things. I no longer have to keep track of files to patch. I no longer have to patch the files on the fly as commits occur. And I no longer have to patch after a cvsup of the working ports tree.

    I have changed the code on my development box last night. It looks good so far. It will eventually go into production.