On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote: > On Wed, Apr 27, 2011 at 6:15 PM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > > On Wed, Apr 27, 2011 at 5:57 PM, Michael J Gruber > > <git@xxxxxxxxxxxxxxxxxxxx> wrote: > > > The idea would be to maintain a registry of "git package descriptors". > The descriptors would be a copy of the whatever descriptor an > activated package would be described by, but probably simply a git > config text file, since we already have the tools to parse those. > > Such a descriptor would have hints about how to use a real package > manager to get the actual package, but would not actually contain any > files from the package itself. > > So, for example, the package source might be bundled in git-core > contrib/ directory, fetchable as a git repo, fetchable as a tar ball, > fetchable as an apt-get package, as brew package etc. The idea is that > gpm would know enough about invoking a real package manager to handle > the actual distribution details. Let me check If I get this right: Say I am a maintainer of enchanced git log -- git logx. It is one .c file, which has to be simply compiled (cc -o git-logx logx.c). If I want to maintain the package in a way you are suggesting, I have to prepare deb, rpm, tarball, zipball, brew (what ever it is, sorry for non-intelligence) and what not. Otherwise, I lose users? *ball is not an option, since we are supporting different architectures and cannot distribute compiled files (unless statically compiled for all architectures we know, which is not good for obvious reasons). Morevoer, different debs for different debian releases (if package depends on libc version)? Although this looks very nice from user point of view, it would be a pain for the extension maintainer... Though it's only one C file. I think shipping it in contrib/ and having extension system is a better option. Though it leaves a hole for dependencies -- if my logx depends on boost or imagemagick, we don't want make git depend on it... Motiejus -- 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