packaging instructions make analogy with git for better explanation
This commit is contained in:
parent
8644690506
commit
27c0190b76
|
@ -131,26 +131,44 @@ Creating a symlink doesn't need a separate program but 'install' also runs
|
||||||
arguments as before).
|
arguments as before).
|
||||||
* Run `gitolite setup`.
|
* Run `gitolite setup`.
|
||||||
|
|
||||||
## packaging gitolite
|
## #package packaging gitolite
|
||||||
|
|
||||||
Here are the requirements for gitolite:
|
Gitolite has broad similarities to git in terms of packaging requirements.
|
||||||
|
|
||||||
* The programs `gitolite` and `gitolite-shell`, and the directories
|
* Git has 150 executables to marshal and put somewhere. Gitolite has the
|
||||||
`commands`, `lib`, `syntactic-sugar`, `triggers`, and `VREF` must all be
|
directories `commands`, `lib`, `syntactic-sugar`, `triggers`, and `VREF`.
|
||||||
in the same directory.
|
|
||||||
|
|
||||||
It doesn't matter what this directory is. As an example, Fedora keeps
|
It doesn't matter what this directory is. As an example, Fedora keeps
|
||||||
git's 150 executables in /usr/libexec/git-core, so /usr/libexec/gitolite
|
git's 150 executables in /usr/libexec/git-core, so /usr/libexec/gitolite
|
||||||
may be a good choice; it's upto you.
|
may be a good choice; it's upto you.
|
||||||
|
|
||||||
The rest of this section will assume you chose /usr/libexec/gitolite as
|
*The rest of this section will assume you chose /usr/libexec/gitolite as
|
||||||
the location. Adjust as needed.
|
the location, and that this location contains the 5 directories named
|
||||||
|
above*.
|
||||||
|
|
||||||
* The program `/usr/libexec/gitolite/gitolite` must then be *symlinked* to
|
* Git has the `GIT_EXEC_PATH` env var to point to this directory. Gitolite
|
||||||
some directory in the PATH. Do not *copy* it; it must be a symlink.
|
has `GL_BINDIR`. However, in git, the "make" process embeds a suitable
|
||||||
|
default into the binary, making the env var optional.
|
||||||
|
|
||||||
* The `Gitolite` subdirectory in `/usr/libexec/gitolite/lib` can stay there,
|
With that said, here's one way to package gitolite:
|
||||||
**OR**, if your distro policies don't allow that, can be put in any
|
|
||||||
|
* Put the two executables (gitolite and gitolite-shell) somewhere in PATH.
|
||||||
|
Then change the 2 assignments to `$ENV{GL_BINDIR}`, one in 'gitolite', one
|
||||||
|
in 'gitolite-shell', to "/usr/libexec/gitolite".
|
||||||
|
|
||||||
|
This is equivalent to "make" embedding the exec-path into the executable.
|
||||||
|
|
||||||
|
**OR**
|
||||||
|
|
||||||
|
Put the two executables `gitolite` and `gitolite-shell` also into
|
||||||
|
/usr/libexec/gitolite (i.e., as siblings to the 5 directories mentioned
|
||||||
|
above). Then *symlink* `/usr/libexec/gitolite/gitolite` to some directory
|
||||||
|
in the PATH. Do not *copy* it; it must be a symlink.
|
||||||
|
|
||||||
|
Gitolite will find the exec-path by following the symlink.
|
||||||
|
|
||||||
|
* The `Gitolite` subdirectory in `/usr/libexec/gitolite/lib` can stay right
|
||||||
|
there, **OR**, if your distro policies don't allow that, can be put in any
|
||||||
directory in perl's `@INC` path (such as `/usr/share/perl5/vendor_perl`).
|
directory in perl's `@INC` path (such as `/usr/share/perl5/vendor_perl`).
|
||||||
|
|
||||||
* Finally, a file called `/usr/libexec/gitolite/VERSION` must contain a
|
* Finally, a file called `/usr/libexec/gitolite/VERSION` must contain a
|
||||||
|
|
Loading…
Reference in a new issue