|Dependencies of optional dependencies [message #663950]
||Wed, 06 April 2011 17:38
| Carsten Reckord
Registered: July 2009
I have a little problem here. I am trying to resolve a feature A that has an
optional dependency to a bundle B which in turn has a non-optional
dependency to a bundle C. Bundle C cannot be resolved, which is kind of by
I would have expected that in this case the optional dependency to B would
simply be unresolved. But instead the whole resolution is unsuccessful.
Is this by design? Or should that be considered a bug?
|Re: Dependencies of optional dependencies [message #664007 is a reply to message #663950]
||Thu, 07 April 2011 03:47
| Thomas Hallgren
Registered: July 2009
This is per design but it could still be considered a bug.
Optional to Buckminster means, if it isn't found, that's OK. No more, no less.
Apparently, the bundle is found here, so Buckminster decides to included it and resolve it's dependencies. That breaks
and one can then argue that it shouldn't matter, just skip everything below the optional bundle. On the other hand, one
can argue that the optional bundle is broken since it cannot be resolved and the fact that it's optional doesn't
necessarily mean that we accept that it is broken. So whether it's a bug or not depends on what mindset you're in.
We must also keep in mind that the resolution performed by Buckminster is somewhat limited in what it can do. It cannot
use a SAT resolver like p2 does because in order to do that, you must first have all the facts. Those facts are unknown
to Buckminster. It finds them while resolving. A best effort in this particular case would of course be to:
a) check if there's exactly one path leading up to the missing bundle
b) if that path includes something that is optional
c) remove everything that was brought in as a result of traversing things from that point provided it wasn't also
brought in by something else.
It's not trivial and the result would still not be perfect, but it could be done.
Your option at present is to control this manually by adding an advisory node to your cquery that will cause the
optional bundle to be skipped.
On 2011-04-06 23:38, Carsten Reckord wrote:
> Hi all,
> I have a little problem here. I am trying to resolve a feature A that has an
> optional dependency to a bundle B which in turn has a non-optional
> dependency to a bundle C. Bundle C cannot be resolved, which is kind of by
> I would have expected that in this case the optional dependency to B would
> simply be unresolved. But instead the whole resolution is unsuccessful.
> Is this by design? Or should that be considered a bug?
Powered by FUDForum
. Page generated in 0.03119 seconds