Install Gitolite with non-standard perl location?
johnso...@gmail.com
Maybe I didn't use the right search terms, but I couldn't find this in the gitolite documentation:
I have an old server whose default perl is older than the 5.10 version that gitolite wants (at least, the "config" command). I can't change the default perl version, but I have a newer version installed as /usr/local/bin/perl. The problem is that all the gitolite tools (including the gitolite command itself) install with /usr/bin/perl as their interpreter path.
Is there a way to specify a non-standard perl path for the Gitolite install to have these paths corrected, or is it a manual post-install task?
If it's manual, is there a safe limited set of tools/scripts that need to have the interpreter changed, or do I need to do a global sed across every file in the gitolite directory?
Thanks,
- Johnson
Sitaram Chamarty
> Hey all,
>
> Maybe I didn't use the right search terms, but I couldn't find this in the gitolite documentation:
>
> I have an old server whose default perl is older than the 5.10
> version that gitolite wants (at least, the "config" command).
official minimum is 5.8.8 -- just remove that "use 5.10.0;" line
and see if things work. It seems to be an error on my part to
add that line in; I'll remove it once you confirm it works. (I
no longer have a way to test such an old perl version, not
without a lot of effort anyway).
If you have a version older than 5.8.8 (released 2006, if I
recall), you may need to fix that. Lots of things in gitolite
may fail then, not just an optional remote-user command.
> I can't change the default perl version, but I have a newer
> version installed as /usr/local/bin/perl. The problem is that
> all the gitolite tools (including the gitolite command itself)
> install with /usr/bin/perl as their interpreter path.
>
> Is there a way to specify a non-standard perl path for the
> Gitolite install to have these paths corrected, or is it a
> manual post-install task?
> If it's manual, is there a safe limited set of tools/scripts
> that need to have the interpreter changed, or do I need to do
> a global sed across every file in the gitolite directory?
and what kind of un-safety are you thinking about?
regards
sitaram
johnso...@gmail.com
> On Wed, Mar 08, 2017 at 03:11:42PM -0800, johnso...@gmail.com wrote:
> > Hey all,
> >
> > Maybe I didn't use the right search terms, but I couldn't find this in the gitolite documentation:
> >
> > I have an old server whose default perl is older than the 5.10
> > version that gitolite wants (at least, the "config" command).
>
> I don't see anything in that command that requires 5.10. The
> official minimum is 5.8.8 -- just remove that "use 5.10.0;" line
> and see if things work. It seems to be an error on my part to
> add that line in; I'll remove it once you confirm it works. (I
> no longer have a way to test such an old perl version, not
> without a lot of effort anyway).
I have 5.8.8, and it seems to work without that, but I don't have any way to test it comprehensively. I don't have any repos with non-standard config settings at this point.
(As an aside, when I first asked this question, I had thought -- because I couldn't get it to run at all -- that the "gitolite config" command would give you configuration values from either the gitolite.conf or .gitolite.rc file. Knowing now what it does, I don't actually need to use it.)
> If you have a version older than 5.8.8 (released 2006, if I
> recall), you may need to fix that. Lots of things in gitolite
> may fail then, not just an optional remote-user command.
>
> > I can't change the default perl version, but I have a newer
> > version installed as /usr/local/bin/perl. The problem is that
> > all the gitolite tools (including the gitolite command itself)
> > install with /usr/bin/perl as their interpreter path.
> >
> > Is there a way to specify a non-standard perl path for the
> > Gitolite install to have these paths corrected, or is it a
> > manual post-install task?
>
> Manual.
>
> > If it's manual, is there a safe limited set of tools/scripts
> > that need to have the interpreter changed, or do I need to do
> > a global sed across every file in the gitolite directory?
>
> I don't know what you mean by "safe". Why would it be unsafe,
> and what kind of un-safety are you thinking about?
"Safe" is ambiguous here, my apologies. Basically, I wouldn't trust it if I did a global replace on "/usr/bin/perl" with the proper perl path throughout the entire gitolite directory. Without both analyzing every instance that occurs *and* foretelling the future in knowing how every occurrence of /usr/bin/perl in all files would be used in future changes, I wouldn't want to put in a process that does a global replace as part of the install. What I was sort of hoping to hear was "you only need to change the perl version on the main gitolite program" or something. I know now that you need to change it in each file in the commands directory, at least. So I guess my long-winded answer ends up with: by "safe", I mean the set of files in which it is known definitely safe to replace the "/usr/bin/perl" string with another path.
> regards
> sitaram
Thanks for your reply and assistance,
- Johnson
Sitaram Chamarty
location, and that should be fine as is, but let me answer
anyway.
It's safe to change "#!/usr/bin/perl" everywhere it appears, to
some other perl (assuming this perl is not older than 5.8.8).
You can just do this everywhere and forget about it.
If you want to do it in as few places as possible, it'll still
be everything; I don't think that string exists in any place
it's not actually needed.
regards
sitaram
Adam Fineman
Adam Fineman
- convert-gitosix-conf used a -w flag. Removed, because there is already a use warnings; statement.
- contrib/commands/compile-1 used a -s flag. Removed, because it isn't actually used.
- src/commands/access used a -s flag. Replaced with Getopt::Long.
Sitaram Chamarty
/usr/bin/env is mainly for quick and dirty scripts and ad hoc
work. Any serious "installed" program, especially one concerned
with security in any form, is better off using a fixed path than
depending on something outside its immediate control.
I believe some BSD packages adjust the shebang line at the time
of package build. Or maybe at install time, I'm not sure. Do
something like that if you really need it to be different from
/usr/bin/perl.
There are actually lots of bad things about this /usr/bin/env
stuff. You could argue that most of them don't apply to
gitolite, but that does not make it OK to use.
I apologise if this offends but I am not budging on this.
regards
sitaram
On Sun, Mar 29, 2020 at 01:52:41AM -0700, Adam Fineman wrote:
> Yesterday, I posted
> 0001-Changed-shebang-from-usr-bin-perl-to-usr-bin-env-per.patch, but there
> were three files that passed arguments to the shebang, which won't work
> with my changes. So, here's another patch to fix that.
>
> This changed three files:
>
> actually used.
> - src/commands/access used a -s flag. Replaced with Getopt::Long.
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/8d39b136-2b53-4cb1-957c-9038fa055692%40googlegroups.com.
> From ee4a73d999b69c4339b209343b5687a8e1fb5140 Mon Sep 17 00:00:00 2001
> From: Git <g...@hotdog.fios-router.home>
> Date: Sun, 29 Mar 2020 08:29:17 +0000
> Subject: [PATCH 2/2] Removed shebang arguments, to be compatible with `env
> perl`.
>
> ---
> contrib/commands/compile-1 | 2 +-
> convert-gitosis-conf | 2 +-
> src/commands/access | 11 +++++++++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/commands/compile-1 b/contrib/commands/compile-1
> index 6d3884f..efc35c7 100755
> --- a/contrib/commands/compile-1
> +++ b/contrib/commands/compile-1
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env perl -s
> +#!/usr/bin/env perl
> use strict;
> use warnings;
>
> diff --git a/convert-gitosis-conf b/convert-gitosis-conf
> index a70f128..c3db6ad 100755
> --- a/convert-gitosis-conf
> +++ b/convert-gitosis-conf
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env perl -w
> +#!/usr/bin/env perl
> #
> # migrate gitosis.conf to gitolite.conf format
> #
> diff --git a/src/commands/access b/src/commands/access
> index e123d22..a972e5d 100755
> --- a/src/commands/access
> +++ b/src/commands/access
> @@ -1,13 +1,20 @@
> -#!/usr/bin/env perl -s
> +#!/usr/bin/env perl
> use strict;
> use warnings;
>
> +use Getopt::Long;
> +
> use lib $ENV{GL_LIBDIR};
> use Gitolite::Rc;
> use Gitolite::Common;
> use Gitolite::Conf::Load;
>
> -our ( $q, $s, $h ); # quiet, show, help
> +our $q = ''; # quiet
> +our $s = ''; # show
> +our $h = ''; # help
> +GetOptions ( 'q' => \$q,
> + 's' => \$s,
> + 'h' => \$h);
>
> =for usage
> Usage: gitolite access [-q|-s] <repo> <user> <perm> <ref>
> --
> 2.17.1
>
Adam Fineman
Sitaram Chamarty
> You don't have to worry about offending me, Sitaram. I certainly won't
> take anything you say personally.
>
> I understand your objections to /usr/bin/env. However, I (and others) need
> to be able to specify which perl installation to use. What if I modified
> gitolite/install to rewrite those hard-coded shebangs to point to the
> interpreter used to run gitolite/install? If you would prefer such a
> solution, let me know and I'll send another patch for you to review.
something. Somehow I got used to the idea that most distros
(and even for example FreeBSD) have it in packages.
Good point (and thanks for reminding me of this). I wouldn't be
averse to an option to "install" that would do that. People who
don't like it can ignore it, and it would work the same as now.
regards
sitaram
Sitaram Chamarty
> Hello Sitaram,
>
> Sorry for the delay in responding -- I am just getting back to this now.
> Please have a look at my attached patch.
I've shortened it quite a bit; please see the attached patch and
let me know if that works for you.
The only *meaningful* change from your version is that I don't
restrict it to the first line. (There are 2 files (Update.pm
and PostUpdate.pm) where it is needed somewhere else in the
file}.
Other than that:
- I think the shorter code is clearer as to intent; one glance
and you know what's happening
- never supported Windows or VMS (is that still a thing?) and
not going to start now
Let me know if this works and I will push it out.
regards
sitaram
Sitaram Chamarty
regards
sitaram
On Sat, Apr 18, 2020 at 06:53:44AM -0400, Adam Fineman wrote:
> Hi Sitaram,
>
> Looks good to me. I tried your version and it works.
>
> Thanks,
>
> Adam