A Plea to Reduce Dependences (e.g., for swig)

Anders F Björklund afb at macports.org
Wed Aug 17 03:44:15 PDT 2011


Ryan Schmidt wrote:

>> Maybe you could provide more detail (or pointers) about the problems that occurred?  In my experience, there are quite a number of things that can go wrong in the MacPorts model of variants/installed/activated, but as I understand it, those fundamentals have stayed the same for a long time despite their potential for problems.
>> 
>> (If the only goal is to minimize problems, a ports system that does nothing at all and contains no ports seems like an ideal trouble-free system.  Useless for users, but highly maintainable with few trouble spots.)
> 
> We have limited time and resources available. We would like to minimize the number of variables, to increase the chance a user will be successfully able to install a port. Requiring dependencies from MacPorts rather than allowing system versions (which can vary drastically across the available Mac OS X releases) was an easy way to do this.

An alternative method, with different drawbacks, is providing
one ports tree for each version. Fink does this, for instance.

MacPorts does it to some extent, e.g. the default compiler is 
depending on which version of Xcode is installed. But not much.
(although it's certainly possible, with the platform variants,
to match different things provided by different system versions)

Another approach is to require binaries or libraries, rather than
require ports. FreeBSD Ports does this, and MacPorts inherited it.

> I don't want to re-open this can of worms. It's a problem we've already solved, by not allowing what's being proposed in this thread.

There's probably a need to further document and explain this policy,
as well as some of the remaining issues about "base" dependencies...

--anders



More information about the macports-dev mailing list