[MacPorts] #70183: installable form(s) of port:MacPorts
MacPorts
noreply at macports.org
Fri Jun 7 11:03:57 UTC 2024
#70183: installable form(s) of port:MacPorts
--------------------------+--------------------
Reporter: RJVB | Owner: (none)
Type: enhancement | Status: new
Priority: Normal | Milestone:
Component: base | Version:
Resolution: | Keywords:
Port: MacPorts |
--------------------------+--------------------
Description changed by RJVB:
Old description:
> `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)?
New description:
`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)?
--
--
Ticket URL: <https://trac.macports.org/ticket/70183#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list