On Wed, Oct 31, 2018 at 03:41:49PM -0400, Matthew Woehlke wrote: > On 31/10/2018 14.26, Oswald Buddenhagen wrote: > > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote: > >> Again, how then does the consuming tool know which qt.core and which > >> qt.gui are compatible with each other? How does it handle the case of > >> finding a qt.core with no matching qt.gui? > > > > as i said below, by the sub-packages constraining their transitive > > dependencies. > > That is insufficient. > no, it's not.
> A.X can be used by itself. A.Y also can be used by itself. However, > mixing different versions of A.X and A.Y is an error. > it's a rather contrived scenario that two components of a package could be used truly independently (without a common dependency within the package), yet still conflict between versions. anyway, let's go with it. > Even if you propose to solve this by having both A.X and A.Y depend on a > "virtual" A.base target of the same version, > that's indeed one way to solve it. another way are "anti-dependencies" like dpkg's Breaks: A.X != <myver> > you still haven't explained how to make it so a consumer can find the > correct version of A in the pathological scenario I outlined without a > global dependency solver. > no, instead i told you that your premise of needing a _global_ solver is wrong. > > that answer might be unnecessarily strict, though. if i build a > > 3rd-party qt module and install it into /opt/myqt, it might be > > compatible with the system qt in /usr. i want to be able to use that > > additional qt module by depending on {qt.{core,gui,3rdpartymodule}}. > > Well, then, don't make it part of the "Qt" package. I don't think you > can have it both ways. (If it's a third-party module, why is it a first > party component of the "Qt" package?) > because users want to think in terms of namespaces, not packages. at least i do. at least for modules that aren't part of "qt" but are hosted on qt-project infrastructure. qtwebkit is an excellent example, and qtwebengine will probably follow soon due to wanting release cycle decoupling. > >> I think you are suggesting that finding build requirements has to be > >> done as a single, monolithic pass; i.e. a project must specify ALL of > >> its requirements before ANY attempt is made to satisfy those > >> requirements. > > > > but that's exactly what you do anyway with the syntax above, within the > > scope of a single package. > > Not quite. [...] > you just spent ~35 lines on ... showing that i'm right. the TTA approach cannot possibly work without the atomic resolution scope provided by the multi-component find_library() statement. and given that constraint, it's absolutely irrelevant to the user what happens behind the scenes. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development