On Thu, Apr 28, 2011 at 5:40 PM, Pau Garcia i Quiles <pgquiles@xxxxxxxxxxx> wrote: > 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) > Ok, I have tried to explain why separating the concerns of package management and plugin management is an appropriate thing to do, and why one directory for each plugin is also a good thing to do. BTW: I thought you actually suggested this concept yourself in your earlier post. I also explained why an activation step is desirable. It is good for performance (since you don't have to resolve across plugin directories on each invocation) and it is good for conflict management (since you get a precise means to identify and prevent conflicts). More over, the application which provides the plugin manager gets to do this conflict detection and prevention, which is exactly the right component to do it. Why? because it understands its own plugin architecture better than any and all plugin authors, package authors or package managers. There is probably only so many times I can explain these principles. As they saying goes - code talks. I'll implement things as I think they should be implemented, incorporating the constructive suggestions that have been made. To be sure, even the insults have helped. Calling the idea of: git install foobar "horrid" and then "utterly horrid" and then "crap" has just helped crystalise in my mind exactly where the correct lines of responsibility should be drawn between, application, plugin and package. It appears that many people still don't get it but there is only so much I can do about that. Anyway, thanks for all your help (constructive and otherwise), jon. -- 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