[MacPorts] #70183: installable form(s) of port:MacPorts

MacPorts noreply at macports.org
Fri Jun 7 11:02:55 UTC 2024


#70183: installable form(s) of port:MacPorts
-------------------------+----------------------
 Reporter:  RJVB         |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  base         |    Version:
 Keywords:               |       Port:  MacPorts
-------------------------+----------------------
 `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"} {
         # consolidate the still dynamic value of
 langselect_keep_locales_file:
         langselect_keep_locales_file ${langselect_keep_locales_file}
         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)?

-- 
Ticket URL: <https://trac.macports.org/ticket/70183>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list