Hi,
On Fri, Jul 29, 2011 at 11:39:37AM +0200, henri GEIST wrote:
> Let say a concret exemple
>
> 3 different teams work on libtiff, libpng, and libjpeg they are totally
> unrelated.
>
> One more team is working on the "gimp". And they need those 3 libs in
> specific versions not necessarily there heads.
>
> One other unrelated team is working on "gqview" and need the same libs
> in other specifics versions (Why should they know what te gimp team
> does)
>
> Neither "gimp" and "gqview" project will contain directory with those
> libs inside. They just depend on them.
>
> And the last team work on the gnome project which need the "gimp" and
> "gqview". It will be this team witch have to care about having both
> "gimp" and "gqview" sharing the same libs version>
> And has well the gnome project will not contain "gqview" and "gimp" in
> its own tree.
> It will also depend on them.
>
> It is just the same with aptitude on debian.
> Each package know there dependency by themselves, does not contain there
> dependencies, and do not need a bigger superpackage to tell them what
> are there own dependencies.
As Jens mentioned already in this example you have a
somemodule A needs a version of lib C higher than X
somemodule B needs a version of lib C higher than Y
relation. Which in the case of submodules is A points to X and B points
to Y. Lets assume X is contained in Y. Since only the superproject knows
about both A and B its the only instance that can resolve this conflict
of dependence on C and can choose Y. In your example aptitude would be
the superproject containing everything.
This is actually (simplified) the way submodule merge is implemented. So
you see if you want both A and B to use the same version of C you need a
superproject recording this knowledge.
Adding the ability to point to git repositories outside of the worktree
does not solve anything but rather creates more problems. Resolving such
dependencies can not be achieved if only A knows that it needs version X
and only B knows that it needs version Y.
Cheers Heiko
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html