Re: tracking submodules out of main directory.

[henri GEIST <henri.geist@flying-robots.com>]

Le mardi 02 août 2011 à 00:12 +0200, Heiko Voigt a écrit :
> 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.

> 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