On Apr 15, 2010, at 5:23 PM, Ryan Schmidt wrote:

> 
> On Apr 15, 2010, at 15:02, Jordan K. Hubbard wrote:
> 
>> On Apr 15, 2010, at 9:43 AM, Eric Le Lay wrote:
>> 
>>> Somehow I had the impression that http://trac.macports.org/ticket/126
>>> was implemented in registry 2.0.
>>> My mistake...
>> 
>> The history of that Trac bug is fascinating.  Has it really been open for 
>> SEVEN YEARS?  Wow. :)
> 
> I remain unconvinced the "bug" should be fixed. If port A depends on port X+Y 
> and port B depends on port X+Z then what? What if X's variants +Y and +Z 
> conflict?
> 
> To take the example from the current thread, about which python version to 
> use, we currently have the ability with our py*-* ports to install for 
> multiple python versions simultaneously. If we switch to having a single port 
> for each python module, we lose that ability. What if port A requires 
> something that only works with python 2.5 and port B requires something that 
> only works with python 2.6? Currently, we can handle that situation; if we 
> change to use variants, we lose it.
> 
> IMHO we should be encouraging the removal of variants from ports (e.g. by 
> moving choices into separate ports), not the proliferation of new variants.


One solution is to install every port (and all of its dependencies) into its 
own "chroot-like" subdirectory with all of the correct dylib linkages. So each 
port you install might have its own personal copy of python built just the way 
it needs it. Since disk space is cheap, all we need to do is come up with 
binaries for each port+variant-combo, plus some other details here and there.

-Bill


_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Reply via email to