On 11/10/06, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Another problem I see is that if on one hand there is a > module for which the latest metadata correspond to what you > want but on the other hand for anotherr module you need an > old version, then no repository version is really good. > > > Xavier > I didn't see the problem there if the tags or repository snapshot is linked only to the module I build (or rebuild). I think the snapshot (being a single number or a set of numbers) must be done after the conflict resolution. Did I misunderstood you?
Maybe I misunderstood the repository metadata version thing. What I understand is that you can only say that you use revision X of the repository metadata when you resolve dependencies. The case of a rebuild is similar to a regular build, you may want to change a dependency. Or you may want to get fixed metadata for a dependency. But not for another dependency. So there are cases where the repository grain metadata version is not enough IMO, because you cannot say that you need this dependency with metadata from repository version X and this other dependency with metadata from repository version Y. But I think you share the same opinion, it's only one more argument. Note that there is an other argument in favor of granular revision numbers.
This solution support much better a possible evolution of the repositories toward a peer-to-peer architecture (see stephano mail "[RT] on package management"). Even if this type of repository is maybe not a good thing for corporate environment, it's a possible evolution that should be anticipated. Now it's true that it introduce additional complexity. But I have some difficulties to imagine what would be the additional complexity for the user, compared to the difficulty of having only one revision number.
I agree. I think that the metadata revision would be "hidden" (i.e. unused and not necessarily known) for most developers, until you really need them, in which case you'd be happy to have them. The complexity introduced is in the tool, but it's feasible if we identify the different cases and the conflicts problems. Xavier Gilles
