[MacPorts] #47192: update: VLC 2.2.0

[MacPorts]

#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