larryv at macports.org
Fri Jan 16 13:43:45 PST 2015
On Jan 16, 2015, at 4:29 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> Bit rot, in source code?
Not literal rot, but as the operating system and developer tools move on, it gets more and more difficult to maintain older software that is not under active development.
> I frankly don't see any reason to prefer subports over independent ports; I'm pretty sure the replaced_by/obsolete functionality will work fine for subports too.
Subports are just an organizational tool. Once in the index, the ports created with the `subport` command are basically equivalent to those created at the "top level" of the portfiles. Replacing subports works fine.
>> To be blunt, tough. If a user really wants
> To be equally blunt: the user is always right.
This is not our general attitude towards this matter.
>> portfile for themselves. The port maintainer
>> ought to pick one variant as the default. My
> Picking a default isn't the same as imposing it, to the point of throwing in an additional Qt install.
> Anyway, that's up to port maintainers to decide for their ports, and not to be imposed as dogma by MacPorts, IMHO.
We prefer users not be allowed to choose their dependencies unless there's a good reason, such as API/ABI incompatibilities, or if the dependencies would take a very long time to build.
(For instance, if llvm-* didn't take so long to build, we'd probably make ld64 and cctools rely on a single version instead of providing variants.)
> Building on 10.6 is (neigh) impossible, but you can build on 10.7+ (or just 10.7?) with backward compatibility for 10.6, and then deploy to 10.6 . I've tested that by using Digia's Qt5 installed on a 10.9 VM and then copying the install dir to my 10.6.8 host. Works fine.
> I'm not sure how that'd work out for the buildbots though ...
A buildslave will not provide archives that a user could not compile themselves.
More information about the macports-dev