VLC: install: /opt/local/bin/vlc-osx: Operation not permitted

[ryandesign (Ryan Carsten Schmidt)]

VLC is trying to install files directly into prefix, bypassing destroot, which is not allowed:

libtool: install: /usr/bin/install -c .libs/vlc-osx /opt/local/bin/vlc-osx
install: /opt/local/bin/vlc-osx: Operation not permitted

[RJVB (René Bertin)]

Oh yes, I do remember you mentioned that before, now.

Sorry for letting this port slip, the past few weeks have been hell here, I hope things will start getting better slowly (in a week or so) and I'll finally be able to spend more time at my Mac (and not just ssh'ed in from a tiny notebook PC).

[RJVB (René Bertin)]

This is weird: bin/Makefile.am has

if HAVE_OSX
if BUILD_VLC
install-data-local:
	cd $(DESTDIR)/$(bindir); mv vlc-osx vlc

endif
endif

suggesting that vlc-osx should be installed correctly because that Makefile also uses DESTDIR everywhere it should.

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

suggesting that vlc-osx should be installed correctly because that Makefile also uses DESTDIR everywhere it should.

You have instructed MacPorts not to set DESTDIR:

if {${subport} ne "lib${name}"} {
    # The VLC.app target does not obey DESTDIR and tries to copy a
    # non-existing folder.
    destroot.destdir \
                    prefix=${destroot}${vlcprefix}

This has been in the port ever since VLC was updated to version 3.0.6. If it was true back then that it did not obey DESTDIR, maybe it is no longer true now in version 3.0.11.

[RJVB (René Bertin)]

Maybe, but that's going to be moot since my current proposal doesn't build anything but fetches the official build. Something the VideoLan people are probably going to be content with, too...

[Tatsh (Andrew Udvare)]

How is port -s going to work if the official build gets pulled in?

I don't see the issue with building and the variants can allow customisation to get features that aren't in the official build.

This port works except for this install step. I would be in favour of seeing it fixed.

[RJVB (René Bertin)]

Well, the thing is that the port has become way to complex to maintain; I've seen remarks like "build failures across the board", and even "kill it or fix it".

It turns out that the official build works from (IIRC) 10.7 all the way to the latest OS version, AND the embedded library can actually be used. I don't see any reason to keep pulling my hair trying to maintain a port that builds only partly on my system and that keeps getting worse with each new release. And I won't, now that I know this solution exists.

What is not in the official build that you think could justify maintaining the existing card house? It could be done of course, even if the "DMG build" became the default install variant (that's how I developped this new Portfile in my local version). I'm willing to prepare such a contraption, but somebody else will have to step up to fix and maintain the build-from-actual-sources part.

NB: it might be possible to replace a sufficient number of the embedded libraries with symlinks to the ones provided by MacPorts, but that would require re-signing the application.

How is port -s going to work if the official build gets pulled in?

Check the PR: ​https://github.com/macports/macports-ports/pull/8718 As with other ports that follow this approach, installing from source is what does the actual pulling-in of the official DMG. A regular, binary install does what it does for any other port that provides the same convenience: it loads and installs a tarball containing the result of the build.

[Tatsh (Andrew Udvare)]

Well, I would still accept this over not having MacPorts manage my VLC installation at all.

As for what VLC stock has vs a custom build, there are a few things but I can't remember if I've been affected by them, especially on macOS. There are a lot of build options for VLC.

NB: it might be possible to replace a sufficient number of the embedded libraries with symlinks to the ones provided by MacPorts, but that would require re-signing the application.

Definitely wouldn't want this.

The only upsides to building a custom VLC is that the libraries are shared and can be updated independently (whether this will work at runtime is always an issue) and that features can be enabled or disabled based on the user's needs.

The issue may be more to do with having to maintain ffmpeg, VLC, mpv, and a lot of other libs to make sure everything stays in sync. On Gentoo this can be a struggle and there's a team for this. I understand MacPorts may not have the same kind of resources available at this time.