Opened 9 years ago
Closed 9 years ago
#50703 closed enhancement (wontfix)
ffmpeg port modifications to enable splitting off legacy port versions with minimal effort
Reported by: | RJVB (René Bertin) | Owned by: | dbevans (David B. Evans) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | has_patch | Cc: | jeremyhu (Jeremy Huddleston Sequoia) |
Port: | ffmpeg |
Description
As announced elsewhere, I've implemented a proof of concept set of changes to the current (2.8.6) FFMpeg port so that it becomes trivial to support a legacy version installed in parallel to a current version. This would make it possible to keep the main port:ffmpeg
at the latest/current release even if because of ABI changes certain dependent ports still require an older version.
The principle is simple: use FFMpeg's configure options to build the binaries and libraries using an appropriate suffix (tentatively called compat_version
in my draft) and accompanying options to ensure that items under ${prefix}/include and ${prefix}/share do not cause version conflicts.
If the port is not configured in legacy mode, symlinks are used to make the relevant items available where they would be in a simple installation. Legacy mode is currently implemented as an inactive port:ffmpeg-${compat_version}
subport, which means that dependents can request that compat_version explicitly.
Thus:
- dependents will find the main ffmpeg port and files as usual
- dependents that need to use a legacy version only need to be patched so that they request the suffixed pkgconfig files (ports not using pkgconfig for this will take a bit more work)
- currently installed dependents will continue to work thanks to the symlinks to (only) the runtime shared libraries (
libfoo.N.dylib
). This is a personal preference of mine; those symlinks could of course also be omitted in legacy mode too.
Note that these modifications can be applied only to the v2.8.6 ffmpeg port; it should be able to co-exist peacefully with a v3.0.0 ffmpeg port built normally. I'd advise building all ffmpeg ports like this in the future though, if the possibility to keep a legacy version around is judged important enough.
Attachments (1)
Change History (3)
Changed 9 years ago by RJVB (René Bertin)
Attachment: | ffmpeg.diff added |
---|
comment:1 Changed 9 years ago by dbevans (David B. Evans)
Cc: | devans@… removed |
---|---|
Owner: | changed from macports-tickets@… to devans@… |
comment:2 Changed 9 years ago by dbevans (David B. Evans)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm closing this in favor of the approach discussed in #50697
Thanks, I'll check it out.