> On Mar 31, 2018, at 8:08 AM, Mojca Miklavec <mo...@macports.org> wrote:
> A few problems I see with this approach: > (a) What happens when a dependency of one of those ports is changed. > Unless you have some CI system in place for this to tell you that a > port needs a revbump at least, you won't know. I don’t find much trouble with this in practice. If some supporting library changes, rev-upgrade seems to detect anything important enough to force a rebuild, and having prebuilt binaries is not an issue for this setup. > (b) Problems like those you mentioned: a dependent port from the main > repository would disable a dependency just because it doesn't know it > could have been built. True. Can’t ask for otherwise from the port authors. > > This approach can work reliably only with sufficient man-hours from > users contributing and/or at least a number of tools to help you > monitor dependencies and dependent ports to at least remind you when > to update something, but ideally also running automated builds on > regular basis. > Perfection is always a goal, but to a large extent, this approach does yield a certain practical effectiveness. In many cases, instead of a message that the port isn’t compatible, you get a version of the port that works, very often fulfilling the need. For example, cmake pegged @ 3.9 will work for many years on Tiger to build any software that needs cmake, and at present, you can get nothing usable from the main MacPorts repo. For older systemsI find it helpful, and there’s little downside to it as the option without it is usually nothing. Of course supporting this kind of a setup is completely not expected from MacPorts port authors. I have no interest in making anyone’s workload increase. Ken
