On Thu, Apr 28, 2011 at 4:08 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: >>> I guess an unmanaged solution could use separate directories for each >>> plugin, but this would imply scanning all these paths each time you >>> invoke git. In my view, symbolic links from a dir already >>> GIT_EXEC_PATH to plugin directories would be a more efficient way to >>> do this. >> >> I think you are overanalyzing the problem > > I don't think so. Perhaps Pau can give us his view on the > desirability of a single directory for all plugins artifacts from a > distribution maintainers perspective. You are thinking too much, this is simpler than what you are trying to do :-) What packages in Linux distributions do is essentially placing files where the FHS says, i. e: - Binaries intended to be used by an average Joe go to /usr/bin - Binaries for internal consumption go to /usr/lib/packagename - Libraries go to /usr/lib - Documentation goes to /usr/share/doc/packagename - Manual pages to go /usr/share/man/manX/command.X.gz - etc Define something like that inside the prefix where git is installed and you are done. As Junio said, git already checks for git-* presence for help, etc. If you want to see more about package organization, go to http://www.debian.org/Packages/unstable/ , go to that package's page and at the bottom there is a "List of files" link. For instance http://packages.debian.org/experimental/git http://packages.debian.org/experimental/amd64/git/filelist BTW, I fail to see why an "activation" step is needed. Either it is installed or it is not. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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