On 2010-4-16 13:19 , Jordan K. Hubbard wrote:
> 
> On Apr 15, 2010, at 5:23 PM, Ryan Schmidt wrote:
> 
>> 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?
> 
> Aha!  This is why I remain convinced that software should depend directly on 
> the depot locations of its dependencies, in which case port X+Y and port X+Z 
> can co-exist just fine on the same system.   I also suspect that it's time 
> that we took a good, hard look at what it means to be "activated" in both the 
> current and high-level senses of the word.  There are lots of ways of putting 
> stuff into a process' filesystem namespace these days, only one of which 
> involves actually making the global filesystem changes in question, the needs 
> of MacPorts and the needs of process sandboxing may also intersect in various 
> interesting ways.  I think there's more architecture in place in the OS to 
> fake things out such that we *don't* have to permute all the configuration / 
> build settings to point at all those depot locations, either, which has 
> always been a sticking point.

I think this is definitely something that should be explored. It's more
of a research problem than a development one at the moment, in the sense
that I don't think anyone really knows how it should be done yet. (As
opposed to a lot of the work I've been doing lately, where I've known
more or less how to do it for quite a while, and it was just a matter of
finding the time and writing the code.)

I don't think depending on variants is completely infeasible, after all
ports can conflict too. At this point we're missing a syntax for
depspecs that includes variants, code to add the variants from the
depspecs to the dependencies when they are opened, a bunch of code to
detect conflicts before we start installing things (macports::upgrade in
particular needs a complete refactor to support this), some more code to
include variants in dependent checks for e.g. uninstall, and a mechanism
to distinguish between variants that are actually depended on as opposed
to requested, so existing deps are only upgraded when they need to be.

This is quite a bit of work and added complexity for something that
we're not really sold on. :-)

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

Reply via email to