On Thursday May 19 2016 12:13:03 Mojca Miklavec wrote: >- etc.
Another thing that will become feasible once we have something like automatic subports is generating those for the runtime libraries (lib*.[0-9]*.dylib). In the simplest implementation those would contain the port version in their name, and be installed automatically when installing the main port and be registered as an additional dependency of any port depending on the main port. This should allow another convenience that doesn't really fit in with current MacPorts guidelines, for dependents of ports like port:ffmpeg. If these don't depend only on the main/monolithic port but also on a subport that can exist independently even if it's created automatically, there is no need for obligatory revbumps when the dependency is updated. Maintainers can still revbump if the update brings important chances, but they can also decide to hold off until their port publishes an update. Evidently those ports would still use the latest version when they are rebuilt, which means maintainers who need to give support can run into issues the reproducible build principle is supposed to prevent. But that too will be a result of their own choice. Evidently even ffmpeg doesn't break ABI compatibility at each release (so something less fine-grained than the port version should probably be used), and ports will need to be careful that vestigial automatic runtime library ports do not enter in conflict with other runtime stuff (so there should be a mechanism to invalidate and uninstall those vestigial ports). And that latter point might just prove too much of a "good thing" :) R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
