[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 larryv@…):

 Replying to [comment:4 rjvbertin@…]:
 > I was under the impression the the Id line was added automatically
 > during a commit, and thought it'd help avoid confusion. Should have
 > realised it also helps in comparing versions...

 The “Id” keyword anchor is not added automatically, but it is replaced
 automatically by the `svn` client if configured properly.

 http://svnbook.red-
 bean.com/nightly/en/svn.advanced.props.special.keywords.html

 > I added one for a different editor, one I happen to be using (in fact
 > I use KDevelop). I think it can be moved to EOF if that's less
 > invasive, I'll want to keep it as long as my name is in the maintainer
 > list.

 Moving it to the end should be fine. Modeline use is up to the maintainer.

 > 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? 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.

 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.

 > > You've added code to enable hfsCompression during extraction. I think
 that's something we should do in MacPorts base, not in individual ports.
 >
 > I agree. And I'll promise to remove the block as soon as it becomes
 redundant, but in the meantime there's no harm in keeping it, right?

 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.

 > > You've rearranged some existing lines which use `file copy` and
 > > `file delete -force`. We may as well clean up those lines: `file
 > > copy` can be replaced with `copy`, and `file delete -force` can be
 > > replaced with `delete`. `file rename` can be changed to `move`.
 >
 > The guide isn't explicit on this: does `delete` have an implicit
 > `-force`?

 Yes: source:tags/release_2_3_3/base/src/port1.0/portutil.tcl#L1068

-- 
Ticket URL: <https://trac.macports.org/ticket/47192#comment:6>
MacPorts <https://www.macports.org/>
Ports system for OS X