#47192: update: VLC 2.2.0 --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: VLC | --------------------------+-------------------------------- Comment (by rjvbertin@…): Replying to [comment:6 larryv@…]:
All of which means that if someone wants to install port:VLC and for some reason has to build from source, s/he will find it takes about twice as long if we make VLC depend on libVLC.
Is libVLC supposed to be something that other software can use?
Evidently, there's little point in providing a port for a library that isn't supposed to be used, eh? :)
If `VLC` and `libVLC` conflict, any software that wants to use libVLC would have to accept both ports as a dependency, which makes things more complicated.
True, though that's what path: style dependencies are for.
How long does VLC take to compile? I expect most users would receive a binary archive, so compile time should not be a major concern.
With the autoreconfig, I'd say between 15 and 30 minutes. Long enough not to want to do the same thing twice in a row. {{{ %> port-check-distributable.tcl -v VLC "VLC" is not distributable because its license "GPL" conflicts with license "OpenSSL" of dependency "openssl" }}} If there's a way to build port:libVLC, "cache" the stuff that port doesn't use and then install that for port:VLC the issue goes away. Alternatively, one could think of providing only port:libVLC, with a +player variant for those who want the full monty.
Ports should only override base functionality if they really have to, and HFS compression is not required to extract VLC. Ryan is right; we should do this in base or not at all. The HFS compression support should not be committed.
Sigh. We're talking about *extending* base functionality with a feature that's completely transparent if you disregard the 1 extra (and highly useful) extract dependency and the reduced footprint. It's not very important for VLC, but for ports like Qt5-mac and Calligra I'd argue it's required for anyone running off an SSD. Of course this is something that can be implemented in base in a matter of seconds, esp. now that there's a tested example... -- Ticket URL: <https://trac.macports.org/ticket/47192#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X