On Monday 30 November 2009, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > We _could_ split up the "git_remote_helpers" package into a > > "git-remote-hg"- specific package, and a "git-remote-cvs"-specific > > package, but that would mean either having two copies of the > > current support code. Alternately, we could create a _third_ > > package containing the common support code, that each of our hg/cvs > > support packages would in turn depend on. I don't think we want to > > go there, at least not yet. > > I think that is typically done by the distros; in the longer term it > would be nicer to them if we did so in our build structure, but I do > not think we are there yet. Agreed. > > Also, to prevent this misunderstanding, we could create a "python" > > subdir in git.git, and move the "git_remote_helpers" into there. > > If (and this is a big if, as we are not migrating to Python) the use > of Python proliferates over time, a single "python" subdir to hold "a > common library" to create the third package will not make sense in > the longer term, as different services written in Python will have > different set of common supporting code, so there will be multiple > common libraries and you would need multiple third packages. You > would probably need multiple directories there, perhaps as > subdirectories of that single toplevel directory you called "python", > so that scripts written in Python would say "import > pythonGit.remoteHelper" or something like that. Yes, I agree that if we get multiple Python support packages, it makes sense to create a "python" subdir, and store each package as a subsubdir of "python". Still, I don't think we need to plan that far ahead now. We can do that restructuring when it becomes necessary. If there are no more objections, I vote for keeping the current structure for now. Have fun! :) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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