On Mon, May 9, 2011 at 6:12 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Mon, May 09, 2011 at 05:49:27PM +1000, Jon Seymour wrote:
>
>> Yep, that was part of the motivation for the suggestion - something
>> that works consistently, assuming only a working git installation.
>>
>> Per one of my other notes, my initial inclination is to provide a
>> patch that implements support for
>>
>> Â Â Âgit --system-extensions-dir
>>
>> which would:
>> Â Â- provide the caller with location that extensions could be
>> installed in (assuming the caller can acquire write privileges)
>> Â Â- provide a guarantee that $(git --system-extensions-dir)/bin will
>> be on the path set up by the git wrapper and $(git
>> --system-extensions-dir)/man will be in the MANPATH searched by git
>> help
>>
>> Extensions could then use this information, together with git
>> --html-path to install themselves into these places using whatever
>> mechanism seems appropriate (either a POSIX shell script or a
>> make/install script).
>
> But is the system extension dir always the right place to do so? If I'm
> not root, then that probably won't be writable (or even if I am, I may
> want to install the extension only for the root user).
>
> If your proposal is for the user to decide on one of:
>
> Âunzip -d "$(git --system-extension-dir)" git-foo.zip
>
> or
>
> Âunzip -d "$HOME/.gitplugins" git-foo.zip
>
> then they can make that decision. But if you're proposing that the
> extension-writer distribute a script, then it's more complicated. They
> would probably need to provide a "--user" versus "--system" option.
>
I am starting to think that deploy-via-zip/tar is unworkable for the
case where the extension wants to supply html, since I think an
attempt has to be made to deploy HTML in the path reported by git
--html-path for reasons of HTML linkability from extension back to
the pages from git-core.
Now, this might not always work, and the install script can either
fail (to be re-run under sudo at users discretion) or degrade
gracefully (install what it can, and warn).
> It would also be tempting to write something like:
>
> Âinstall_dir() {
> Â Âif test "`id -u`" = "0"; then
> Â Â Âgit --system-extension-dir
> Â Âelse
> Â Â Âecho $HOME/.gitplugins
> Â Âfi
> Â}
>
> but that is:
>
> Â1. Not portable.
>
> Â2. Does not allow for user-only installation by root.
>
> But all of this is a packaging best-practices issue, not an issue of
> what git needs to do to support it (you _could_ address the portability
> issue by having "git --preferred-extension-path" that did the
> appropriate platform-specific UID check, but that still doesn't address
> the second point).
So, suppose we call it --preferred-extension-path*, then if the user
(root or otherwise) defines
git config core.preferrred-extension-path ${HOME}/.gitplugins
then they get to choose where the installer next run will install extensions.
Also, this would only be a default - installation scripts could have a
mechanism to specify an override on the command line. Of course, if
they supply the override and it is not consistent with
--preferred-extensions-path/core.preferred-extensions-path then they
need to take steps to install that the bin directory is in the PATH,
but that's a decision they take themselves as an alternative to
acquiring the privileges required to modify the directory reported by
git --preferred-extensions-path
The idea is for core to provide extension installers with just enough
information that their installs will work and be discoverable by the
core and enough control for distributions to determine the preferred
location for such extensions.
* I would prefer --preferred-extension-dir rather than
--preferred-extension-path, since I think this name should specify a
single directory and not a list (otherwise the choice of destination
would be ambigiuous). I realise this creates an inconsistency with
--html-path and if consistency is preferred (or I have misinterpreted
what path normally means), I am happy to use
--preferred-extension-path.
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