#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