#19141: Update libmp4v2 --------------------------------+------------------------------------------- Reporter: anddam@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Component: ports Version: 1.7.0 | Keywords: Port: libmp4v2 | --------------------------------+------------------------------------------- Comment(by cedric.luthi@…): In #19142, anddam said: ''We could create a new port for libmp4v2 like libmp4v2-2 or mp4v2 as it is the actual project name. Or we could just leave it at 1.5 as there's no point in upgrading a library that noone is using anyway, but this kind of discussion should rather be done in #19141.'' I'm in favor of a new port named mp4v2. I don't agree that there is no point in upgrading: the new mp4v2 on googlecode includes some new tools, such as `mp4chaps` which does not exist in version 1.5. As mentioned, headers are not a problem, version 1.5 installs only `/opt/local/include/mp4.h` and version 2.0 installs `/opt/local/include/mp4v2/mp4v2.h` As both versions are installing `/opt/local/lib/libmp4v2.dylib` there might be problems if version 2.0 is not backward compatible. -- Ticket URL: <http://trac.macports.org/ticket/19141#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#19141: Update libmp4v2 ---------------------------------+------------------------------------------ Reporter: anddam@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 1.7.0 Keywords: | Port: libmp4v2 ---------------------------------+------------------------------------------ Comment(by devans@…): Yes, initial testing shows several incompatibilities. I am against yet another version of this port as we have enough cases of problems caused by conflicts between multiple versions of ports on the system. As it is now we already have two versions (mpeg4ip and libmp4v2) that have been massaged so they do not conflict. There are a number of important audio/multimedia applications that depend on libmp4v2 so I propose not to commit this sort of port until it can be tested and shown to not break any of those. faac is an important example. So I guess I'm voting for "if it's not broke don't fix it" until we can guarantee that no existing ports will be broken and there is some positive benefit to a change. The most direct evidence of this would be for upstream developers to adopt this version as a dependency, so if you feel strongly, I advise that you lobby them to switch or at least support this new version in addition to the old. Another approach would be to commit this as libmp4v2-devel with the understanding (as with all devel ports) that it conflicts with libmp4v2 and may or may not work. Maintainers of dependents of libmp4v2 could modify their dependencies using a path rather than port if they desire to allow either to satisfy their dependency but with the current port being the default until any bugs are ironed out. This would allow those that want to try it to do so but not interfere with functionality of the currently installed dependent ports for the general user. I'd like to see some input from the maintainers of the dependent ports involved (cc'd) as to their feelings about this. -- Ticket URL: <http://trac.macports.org/ticket/19141#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS