Travis: Use the normal MacPorts installer

[ryandesign (Ryan Carsten Schmidt)]

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 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 .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, 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 macports-base/config/RELEASE_URL​.

[ryandesign (Ryan Carsten Schmidt)]

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.

[l2dy (Zero King)]

It is documented in the ​release process.

[l2dy (Zero King)]

Replying to ryandesign:

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.

It was done to skip the selfupdate in the postflight script, which would download and extract base and ports into /opt/local/var/macports/sources. ​https://github.com/macports/macports-base/blob/15c064eb508ce0c9bb82c8cfb216cd36ad1895d8/.travis.yml#L17

- sed -i "" "s/-v selfupdate/version/" portmgr/dmg/postflight
- sudo install portmgr/dmg/postflight /opt/local/

[ryandesign (Ryan Carsten Schmidt)]

Replying to l2dy:

It is documented in the ​release process.

Oops, I didn't see that there, and I didn't realize that just doing that would automatically build and upload the new version to a place Travis could use it. Still, if that step weren't necessary, it would be simpler.

[ryandesign (Ryan Carsten Schmidt)]

Replying to l2dy:

Replying to ryandesign:

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.

It was done to skip the selfupdate in the postflight script

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

[l2dy (Zero King)]

Replying to ryandesign:

Oops, I didn't see that there, and I didn't realize that just doing that would automatically build and upload the new version to a place Travis could use it. Still, if that step weren't necessary, it would be simpler.

We can merge the Travis configurations (in a new commit, not git-merge), but I'd suggest creating a new bintray account for uploading (currently using l2dybot). Travis CI supports deploying tags only: ​https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on.

[l2dy (Zero King)]

Replying to ryandesign:

Replying to l2dy:

Replying to ryandesign:

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.

It was done to skip the selfupdate in the postflight script

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

Sure. That's the only reason preventing us from using the pkg installers.

[ryandesign (Ryan Carsten Schmidt)]

Replying to l2dy:

We can merge the Travis configurations (in a new commit, not git-merge), but I'd suggest creating a new bintray account for uploading (currently using l2dybot). Travis CI supports deploying tags only: ​https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on.

I don't understand the issues you're talking about, but we do have a "macports" account at Bintray that's not currently being used for anything.

[l2dy (Zero King)]

Replying to l2dy:

Replying to ryandesign:

Replying to l2dy:

Replying to ryandesign:

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.

It was done to skip the selfupdate in the postflight script

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

Sure. That's the only reason preventing us from using the pkg installers.

And of course, the bootstrap.sh script in macports-ports has to be modified to auto-discover the current version.

[ryandesign (Ryan Carsten Schmidt)]

Replying to l2dy:

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

Sure. That's the only reason preventing us from using the pkg installers.

I'll see what I can do about adding this to the installer pkg. I have some ideas.

[l2dy (Zero King)]

Replying to ryandesign:

Replying to l2dy:

We can merge the Travis configurations (in a new commit, not git-merge), but I'd suggest creating a new bintray account for uploading (currently using l2dybot). Travis CI supports deploying tags only: ​https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on.

I don't understand the issues you're talking about, but we do have a "macports" account at Bintray that's not currently being used for anything.

I'd like to use a more "official" account for uploading, e.g. macportsbot. macports on Bintray is currently an organization, not a user, and only users can have API keys to put into .travis.yml (with encryption).

[neverpanic (Clemens Lang)]

I've kept the tarball that gets extracted and haven't used to official installer, but at least those tarballs are now on a more official account, plus their generation is automated by a CI in macports-base.