Opened 4 months ago

Last modified 4 months ago

#70183 new enhancement

installable form(s) of port:MacPorts

Reported by: RJVB (René Bertin) Owned by:
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc: jmroot (Joshua Root)
Port: MacPorts

Description (last modified by RJVB (René Bertin))

Port:MacPorts came up in #51516 so I thought I'd spin off a ticket to outline an idea for this port that I've been working on.

I've been using a personal -devel version of the port to maintain a "base" install that follows the master branch (with variable delays). At first I'd destroot the port to assess what would change etc., for a while I probably used porg (ex paco) to manage the installed files and then moved to using port dpkg to create and install .deb packages via port:dpkg.

Last week I came up with the idea of having an "altdevel" port:

if {![string match /* ${prefix}]} {
    # this is for `portindex`:
    set prefix "/opt/local"
    ui_debug "Prefix not set to a path, setting it to /opt/local"
}

if {![info exists current_prefix]} {
    set current_prefix  ${prefix}
    ui_debug "current_prefix set to ${current_prefix}"
} else {
    ui_debug "current_prefix already set to ${current_prefix}"
}

if {![info exists altprefix]} {
    if {${prefix} eq "/opt/local"} {
        set altprefix "/alt/local"
        ui_debug "prefix=/opt/local => altprefix=${altprefix}"
    } elseif {${prefix} eq "/alt/local"} {
        set altprefix "/opt/local"
        ui_debug "prefix=/alt/local => altprefix=${altprefix}"
    } else {
        ui_error "Unforeseen 'prefix' value \"${prefix}\""
        return -code error "Unforeseen configuration, bailing!"
    }
} else {
    ui_debug "altprefix already set to ${altprefix}"
}

and further down:

if {${subport} ne "${name}"} {
    if {${subport} eq "${name}-altdevel"} {
        set prefix ${altprefix}
        ui_debug "${subport} uses prefix=altprefix=${prefix} !"
        configure.args-append \
                    --with-no-root-privileges
    }
    fetch.type      git
##    See https://github.com/macports/macports-base/releases/latest for release info and the "number of commits
##    to master since release"; use the commit before the 1st one in that list as the target for the custom
##    version tag.
##     after `git tag RJVB-v2.7.1 -a -m "RJVB 2.7.1 release tag" 8e66a82b3fb50812c05a19b7bb49e1eec86ed708`
##     after `git tag RJVB-v2.9.3 -a -m "RJVB 2.9.3 release tag" b6878b17059c12ff056931fa50ae2172074e57ea`
    git.branch      8e677f9d968807a539c1b9ab4fd039751a6d74ed
    version         2.9.3.66
    # the version from autoconf (config/macports_version), which is isn't very useful in the master branch:
    set macports_version 2.9.99

(full Portfile: https://github.com/RJVB/macstrop/blob/master/sysutils/MacPorts/Portfile)

With this code, port:MacPorts-devel will always install to the current $prefix by default (unless you unset +keep_prefix which I made a default variant). A new port:MacPorts-altdevel will install

  • to /alt/local if $prefix=/opt/local
  • to /opt/local if $prefix=/alt/local.

The idea is that one can install port:MacPorts-altdevel through the main MacPorts instance to test-drive a new version. It wasn't my initial intention but I realised that if those tests are satisfactory one could install port:MacPorts-altdevel once more, this time through the alt. instance ... and that would upgrade the main instance. Call it a permanent, reciprocal bootstrap scheme if you want.

I haven't yet actually tried it as I want to profit from having an older "base" install to see what can go wrong if a port:MacPorts-pextlib is introduced and installed by people who hold off self-updating MacPorts as much as I do.

What do you think, will this scheme work or will it self-destruct? In particular, is it even possible to downgrade MacPorts base (aka activate an older version of the port when installed as per the above)?

Change History (2)

comment:1 Changed 4 months ago by RJVB (René Bertin)

Description: modified (diff)

comment:2 Changed 4 months ago by RJVB (René Bertin)

(PS: the --with-no-root-privileges argument gave me a chuckle ... reminded me of the "Look ma, with no hands" I probably yelled only once from my infant bicycle :) )

Note: See TracTickets for help on using tickets.