[MacPorts] #33048: ffmpeg: Update to 0.10
MacPorts
noreply at macports.org
Thu Feb 2 05:11:47 PST 2012
#33048: ffmpeg: Update to 0.10
--------------------------------+-------------------------------------------
Reporter: ocroquette@… | Owner: devans@…
Type: update | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.0.3
Keywords: haspatch | Port: ffmpeg
--------------------------------+-------------------------------------------
Comment(by markus.doits@…):
imo, the port simply should be updated. If things break with other
programs, it is time to fix them there. There is no other solution to have
a clean and up to date macports economy.
Of course, when things break, there will be some annoyance. But if it
breaks for a lot of people, there will be someone to fix it (if there's no
active maintainer).
Another idea: an intermediate port "ffmpeg-new" could be introduced, which
"provides ffmpeg". I don't know if such thing exists for macports, but if
a user wants to install something that depends on "ffmepg", but has
installed the port "ffmpeg-new" which "provides ffmpeg", it should mark
the dependency "ffmpeg" as satisfied.
Users and maintainers could then be urged to use "ffmpeg-new" to build new
ports and old ports should be tested and be updated to compile with
"ffmpeg-new" (maybe having a variant +ffmpeg_new to explicitly depend on
"ffmpeg-new" on the meantime). After some not so long deadline (max 3
months?), announced clearly for everyone, the old legacy port ffmpeg is
simply updated to 0.10 and "ffmpeg-new" is removed. Maintainers had time
to test and update their ports.
And users using "ffmpeg-new" (who do this on purpose and know there will
be other broken ports) will see if their other installed ports break, and
file a bug for them. With this way, some errors can be catched before
ffmpeg is updated "for the public".
Third idea: provide a "ffmpeg-new" port with renamed binaries and
libraries etc. (or installed with another prefix), that does not interfere
with the legacy ffmpeg. So both things can be installed together, old
ports can continue to depend on "ffmpeg", new ports can depend and compile
with "ffmpeg-new" (or continue to use the legacy ffmpeg). This looks like
the easiest solution.
All approaches require a quite amount of work, but this comes from lagging
behind several versions. Updates should be published fast. At least, if
macports wants to provide up to date software (which I assume it wants,
right?).
--
Ticket URL: <https://trac.macports.org/ticket/33048#comment:5>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list