[MacPorts] #57698: Travis: Use the normal MacPorts installer

[MacPorts]

#57698: Travis: Use the normal MacPorts installer
----------------------------+---------------------
Reporter: ryandesign | Owner: admin@

Type: defect | Status: new
Priority: Normal | Milestone:
Component: server/hosting | Version:
Keywords: | Port:
----------------------------+---------------------
For Travis, we currently use a custom MacPorts installer built
specifically for Travis. This is an additional asset that needs to be
produced every time we release a new version of MacPorts. (And it's not
currently documented in the [browser:macports-
base/portmgr/ReleaseProcess.md release process] how to do that.) It would
be great if we could eliminate that requirement and have Travis use the
normal MacPorts installer.

From [browser:macports-base/***@travis-ci .travis.yml], it looks
like the differences between the regular MacPorts installer and the build
for Travis are:

* The Travis build is packaged as a .tar.bz2 instead of a .pkg

From my point of view, there is no need for this difference. It's no
problem to install a .pkg from the command line using the `installer`
command.

* The Travis build modifies the postflight script so that it does not run
selfupdate

It's a little more work, but the postflight script could be extracted
from the pkg, modified, and put back into the pkg before installing the
pkg. Better yet, maybe we can find a way (argument? environment variable?
config file? subpackage?) to let the user running `installer` specify
whether selfupdate should be run; this would benefit not only our Travis
configuration but anybody else needing similar functionality.

* The Travis build copies the postflight script into /opt/local; after
extracting the tarball, [browser:macports-ports/_ci/bootstrap.sh
bootstrap.sh] runs it and deletes it

This would be unnecessary if it were a pkg since it would run
automatically.

* The Travis build copies the .tcl files into /opt/local

I don't know why it does that. If there is a reason, perhaps it can be
addressed another way.

If the problem is that Travis doesn't know what version of the MacPorts
installer to download, it could determine the current version by querying
[browser:macports-base/config/RELEASE_URL].

[MacPorts]

#57698: Travis: Use the normal MacPorts installer
-----------------------------+---------------------
Reporter: ryandesign | Owner: admin@

Type: defect | Status: new
Priority: Normal | Milestone:
Component: server/hosting | Version:
Resolution: | Keywords:
Port: |
-----------------------------+---------------------

Comment (by ryandesign):

In fact, Travis is currently using MacPorts 2.5.2, instead of the current
version 2.5.4, because of this. That's not good.

[MacPorts]

#57698: Travis: Use the normal MacPorts installer
-----------------------------+---------------------
Reporter: ryandesign | Owner: admin@

Type: defect | Status: new
Priority: Normal | Milestone:
Component: server/hosting | Version:
Resolution: | Keywords:
Port: |
-----------------------------+---------------------

Comment (by l2dy):

It is documented in the [https://github.com/macports/macports-
base/blob/master/portmgr/ReleaseProcess.md#make-the-release-available-for-
pull-request-checks-on-travis-ci release process].