Re: tracking submodules out of main directory.

From: henri GEIST <henri.geist@flying-robots.com>
Date: Aug 2, 2011, 12:58 UTC
Message-ID: <1312289914.3261.836.camel@Naugrim.eriador.com>
In-Reply-To: <20110801221203.GA31614@book.hvoigt.net>

Le mardi 02 août 2011 à 00:12 +0200, Heiko Voigt a écrit :

Show 41 quoted lines

> 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.
>

I do not want to have a superproject. just as with aptitude. Each package store its own dependencies itself. I do not want to need a super package who now every dependencies of every possible packages. First because it is impractical to maintain an exhaustive list of all possible packages (including unofficial ones.) Secondly because I have no need for this and it will require somme more works. Third for different people witch use and share there own subset off unofficial package they needs to cook a specific super package for each unique case.

> 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.

And tha is my problem.

Show 5 quoted lines

> 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.
>

Why not it work perfect for me and for debian as well. Yes I now for speed purpose they scans all the package header and store their dependency requirement in a database. but it is only for speed and it is automatic generated by the info "In the packages them selves". I do not think they ever edit it by hand to define the dependency in the DB.

In fact I suppose this by what I seen by using it I never looked in the apt source code.

	Henri GEIST