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