Moving to new VLC packaging method causes "Check for Update" to auto-trigger

[jasonliu-- (Jason Liu)]

In ​GitHub PR#8718, the method of installing the VLC port was changed in a fundamental way. It looks like it now performs what essentially looks like a "brew cask"-style installation of the upstream authors' DMG installer.

As of the submission of this Trac ticket (2020-02-10), the VLC port version is 3.0.11.1. VideoLAN.org just released version 3.0.12. After installing or upgrading VLC to vlc @3.0.11.1, upon launching VLC, the check-for-updates functionality immediately auto-triggers, and a window pops up offering to upgrade to VLC to version 3.0.12. I haven't actually tried clicking on the "Install Update" button, but I suspect that it will behave in the normal way of downloading the new VLC and performing an in-place upgrade. Wouldn't this break the "MacPorts identity" of the package?

If I recall correctly, the old method of packaging VLC actually disabled the "Check for Update" functionality. Should we not be doing the same for the new package?

[kencu (Ken)]

Please review all the extensive discussions on that PR, and I believe an associated ticket.

The current maintainer, RVJB (Rene) is an extremely experienced MacPorts user -- you should look at his github MacPorts repo sometime for inspirations.

He reached the point where it is no longer possible to build VLC, as outlined on those PRs and tickets.

He had a PR in the queue for many months for this change, that needed to be rebased twice, and obtained almost no opinions or feedback on this from anyone.

I discussed this with him extensively. It's true, he installs a binary -- that was prior to the recent "discussions" on the mailing list about this.

In the end, it was either this PR, or remove VLC/VLC2 and other similar ports from MacPorts altogether. Personally I am fine with removing it -- I install VLC from the VLC website, after all, and I think many people do.

Be that as it may, he wanted to approach it this way, and it made it in before I shut down any further cask installs (at least by me).

If it is in your opinion a terrible idea, I invite you to discuss with him, and consider dumping VLC/VLC2 from MacPorts if so.

Rene -- any input here?

[jasonliu-- (Jason Liu)]

I'm not criticizing the decision to move to a "brew cask"-style installation. This Trac ticket is simply pointing out that by going that route, the "Check for Update" functionality is suddenly enabled and getting auto-triggered when the app gets launched.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jasonliu--:

I haven't actually tried clicking on the "Install Update" button, but I suspect that it will behave in the normal way of downloading the new VLC and performing an in-place upgrade.

Presumably it would. Either that or say it cannot due to lack of permissions.

Wouldn't this break the "MacPorts identity" of the package?

Yes, it would.

If I recall correctly, the old method of packaging VLC actually disabled the "Check for Update" functionality. Should we not be doing the same for the new package?

If we can, yes we should.

[RJVB (René Bertin)]

It looks like I might be able to disable the auto-updating feature ... but that will probably invalidate any signing of the application bundle...

EDIT: found another possible solution to look into: ​https://www.jamf.com/jamf-nation/discussions/27732/disable-autoupdate-vlc-media-player-in-mac

The thing is that this will disable auto-updating in every VLC copy you might have. So maybe I'd do the defaults write in the post-activate and the equivalent defaults delete in the pre/post DEactivate?

[RJVB (René Bertin)]

This should work to disable the auto-update checking (there's nothing I can do about manual checking AFAICT):

Add to the existing post-activate block:

    system "defaults write /Library/Preferences/org.videolan.vlc SUEnableAutomaticChecks" 0"

Under that block, add:

pre-deactivate {
    system "defaults delete /Library/Preferences/org.videolan.vlc SUEnableAutomaticChecks"
}

(a post-deactivate would be fine too of course).

Maybe someone with commit access can take care of these simple mods? Or should I do the PR dance yet again to update the port at the same time?