Skip to contentSkip to conversation

Why does git-core 0.99.7 require python 2.4?

DISCUSSION H. Peter Anvin 6 participants 18 messages Jun 15, 2016 Kbuild

lore
Share & tools
lore

H. Peter Anvin

author
#0 lore raw

I just tried to update the kernel.org hosts to git-core 0.99.7, but I got stuck due to the fact that git-core 0.99.7 requires python >= 2.4, which isn't in RHEL4 (python-2.3.2) nor in FC3 (python-2.3.4).

Updating Python beyond what the distribution provides is a major operation.

Can it be changed to work with python 2.3, to give a bit of leeway?

-hpa

#1 lore raw
Quoted 8 lines · H. Peter Anvin

I just tried to update the kernel.org hosts to git-core 0.99.7, but I got stuck due to the fact that git-core 0.99.7 requires python >= 2.4, which isn't in RHEL4 (python-2.3.2) nor in FC3 (python-2.3.4).

Updating Python beyond what the distribution provides is a major operation.

Can it be changed to work with python 2.3, to give a bit of leeway?

It is git-merge-recursive which wants Python 2.4. Unfortunately Python 2.3 do not ship with the 'subprocess' module which is currently used by the 'recursive' merge strategy. RPMs for Python 2.4 can be downloaded from http://www.python.org/2.4.1/rpms.html

Python isn't used by the rest of Git so if you don't use the recursive merge strategy it will work fine without Python.

Not supporting one of the major Linux distributions isn't ideal though, so maybe we should do something about this. I will have a look at rewriting the code to not use subprocess.

- Fredrik

#2 lore raw
Quoted 3 lines · Fredrik Kuivinen

Not supporting one of the major Linux distributions isn't ideal though, so maybe we should do something about this. I will have a look at rewriting the code to not use subprocess.

Thanks -- I personally feel that it would be best to just let FC catch up, solving this problem for us, while you spend your time on other things first.

Peter, if you feel strongly about it I'd do 0.99.7.1 removing the 'requires python >=2.4', but as Fredrik says the only thing that uses Python 2.4 is his recursive merge, and it is not something we use without the user explicitly asking for it. We can consider it as the same status as send-email or archimport which cannot work without Perl modules necessary for their operation, so if you can install bypassing requires- check that would work equally well.

author
#3 lore raw
Quoted 10 lines · Junio C Hamano
Quoted 3 lines · Fredrik Kuivinen

Not supporting one of the major Linux distributions isn't ideal though, so maybe we should do something about this. I will have a look at rewriting the code to not use subprocess.

Thanks -- I personally feel that it would be best to just let FC catch up, solving this problem for us, while you spend your time on other things first.

The problem isn't FC, the problem is RHEL, generally used on machines for which an OS update it's huge deal.

Quoted 8 lines

Peter, if you feel strongly about it I'd do 0.99.7.1 removing the 'requires python >=2.4', but as Fredrik says the only thing that uses Python 2.4 is his recursive merge, and it is not something we use without the user explicitly asking for it. We can consider it as the same status as send-email or archimport which cannot work without Perl modules necessary for their operation, so if you can install bypassing requires- check that would work equally well.

My suggestion would be to fork off the recursive merge into a separate binary package which can have the python >= 2.4 requirement (unless Fredrik just fixes it.)

-hpa

#4 lore raw
Quoted 3 lines · H. Peter Anvin

My suggestion would be to fork off the recursive merge into a separate binary package which can have the python >= 2.4 requirement (unless Fredrik just fixes it.)

It sounds like the right thing to do, not that I know much about how RPM world deals with situations like this (aside from what I learnt from the list). If we go this route probably we should the same for gitk and git-send-email as well?

author
#5 lore raw
Quoted 10 lines · Junio C Hamano
Quoted 1 line · H. Peter Anvin

My suggestion would be to fork off the recursive merge into a separate binary package which can have the python >= 2.4 requirement (unless Fredrik just fixes it.)

It sounds like the right thing to do, not that I know much about how RPM world deals with situations like this (aside from what I learnt from the list). If we go this route probably we should the same for gitk and git-send-email as well?

Yes, that probably would make sense, at least for gitk.

I'll try to work on the spec file. It's a bit messier than I'd like, because a whole bunch of wildcard patterns don't work anymore.

-hpa

author
#6 lore raw
In reply to Junio C Hamano
Quoted 11 lines · Junio C Hamano
Quoted 1 line · H. Peter Anvin

My suggestion would be to fork off the recursive merge into a separate binary package which can have the python >= 2.4 requirement (unless Fredrik just fixes it.)

It sounds like the right thing to do, not that I know much about how RPM world deals with situations like this (aside from what I learnt from the list). If we go this route probably we should the same for gitk and git-send-email as well?

I thought about it some more, and it really comes down to what you actually want to do with the recursive merge stuff. If you want it to be part of the standard git core, then probably the right thing is to just make it work with a lower baseline.

-hpa

#7 lore raw

It looks like Python2.4's subprocess module is pure Python, and works with python2.3.

Could subprocess.py just be included in git?

Jeff

author
#8 lore raw
Quoted 4 lines · [email protected] wrote:

It looks like Python2.4's subprocess module is pure Python, and works with python2.3.

Could subprocess.py just be included in git?

I think that would be the best solution.

-hpa

#9 lore raw
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines · [email protected] wrote:

It looks like Python2.4's subprocess module is pure Python, and works with python2.3.
Could subprocess.py just be included in git?

I think that would be the best solution.

OK, it appears that I'd better be doing a 0.99.7a real soon to only include:

- merge-recursive not requiring 2.4 but checking the result from 'import subprocess', and optionally install its own subprocess.py (I could do this myself but Fredrik could help me);

- 'git-init-db' template installation fix from Pasky (thanks both Peter and Petr for diagnosis and fix);

- 'git checkout' error message fix from Linus;

- 'git show-branch' not barfing on corrupt repository (me);

- not installing compatibility symlink for commands we do not install (Patrick Mauritz).

There are other patches for some other things discussed on the list since 0.99.7 but they do not belong to "fixing breakage" category.

#10 lore raw

Ship our own copy of subprocess.py

Quoted 4 lines · Junio C Hamano

- merge-recursive not requiring 2.4 but checking the result from 'import subprocess', and optionally install its own subprocess.py (I could do this myself but Fredrik could help me);

I'll be cutting 0.99.7a with this, to help RHEL instalation. Proofreading appreciated.

------------
so people without the latest Python could run merge-recursive.

Signed-off-by Junio C Hamano <[email protected]>

---

 Makefile             |    6 
 git-core.spec.in     |    8 
 gitMergeCommon.py    |    6 
 compat/subprocess.py | 1165 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 1176 insertions(+), 9 deletions(-)
 create mode 100644 compat/subprocess.py

343d35c9166cf1713eb2787c3506fd2663466262

Makefile +6 -0
@@ -23,6 +23,8 @@
 #
 # Define NO_GETDOMAINNAME if your library lack it (SunOS, Patrick Mauritz).
 #
+# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
+#
 # Define COLLISION_CHECK below if you believe that SHA1's
 # 1461501637330902918203684832716283019655932542976 hashes do not give you
 # sufficient guarantee that no collisions between objects will ever happen.

@@ -117,6 +119,10 @@ PROGRAMS += git-ssh-pull git-ssh-push
 PYMODULES = \
 	gitMergeCommon.py
 
+ifdef WITH_OWN_SUBPROCESS_PY
+	PYMODULES += compat/subprocess.py
+endif
+
 ifdef WITH_SEND_EMAIL
 	SCRIPT_PERL += git-send-email.perl
 endif
git-core.spec.in +5 -3
@@ -9,7 +9,7 @@ URL: 		http://kernel.org/pub/software/sc
 Source: 	http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
 BuildRequires:	zlib-devel, openssl-devel, curl-devel  %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires:	rsync, rcs, curl, less, openssh-clients, python >= 2.4, tk
+Requires:	rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk
 
 %description
 This is a stupid (but extremely fast) directory content manager.  It

@@ -23,11 +23,13 @@ elsewhere for tools for ordinary humans 
 %setup -q
 
 %build
-make COPTS="$RPM_OPT_FLAGS" prefix=%{_prefix} all %{!?_without_docs: doc}
+make COPTS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
+     prefix=%{_prefix} all %{!?_without_docs: doc}
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} \
+make DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
+     prefix=%{_prefix} mandir=%{_mandir} \
      install %{!?_without_docs: install-doc}
 
 %clean
gitMergeCommon.py +0 -6
@@ -11,12 +11,6 @@ def printList(list, file=sys.stdout):
         file.write(' ')
     file.write('\n')
 
-if sys.version_info[0] < 2 or \
-       (sys.version_info[0] == 2 and sys.version_info[1] < 4):
-    die('Python version 2.4 required, found', \
-        str(sys.version_info[0])+'.'+str(sys.version_info[1])+'.'+ \
-        str(sys.version_info[2]))
-
 import subprocess
 
 # Debugging machinery
compat/subprocess.py new file +1165 -0

1,165 lines not on this page · raw message

#11 lore raw

Re: Ship our own copy of subprocess.py

Quoted 10 lines · Junio C Hamano
Quoted 4 lines · Junio C Hamano

- merge-recursive not requiring 2.4 but checking the result from 'import subprocess', and optionally install its own subprocess.py (I could do this myself but Fredrik could help me);

I'll be cutting 0.99.7a with this, to help RHEL instalation. Proofreading appreciated.

The patch looks good. I am obviously too slow for this kind of thing :)

Thanks.

- Fredrik

#12 lore raw

Re: Ship our own copy of subprocess.py

Quoted 8 lines · Fredrik Kuivinen
Quoted 7 lines · Junio C Hamano
Quoted 4 lines · Junio C Hamano

- merge-recursive not requiring 2.4 but checking the result from 'import subprocess', and optionally install its own subprocess.py (I could do this myself but Fredrik could help me);

Quoted 5 lines
Quoted 3 lines

I'll be cutting 0.99.7a with this, to help RHEL instalation. Proofreading appreciated.

The patch looks good. I am obviously too slow for this kind of thing :)

Quick issue: the subprocess.py thing seems to be the old-style BSD license with the anti-advertizing clause. It's not compatible with the GPL.

Now, it's arguable that this is "mere aggregation" (git is bulding a mini-distribution), but still..

Linus

author
#13 lore raw

Re: Ship our own copy of subprocess.py

Quoted 5 lines · Linus Torvalds

Quick issue: the subprocess.py thing seems to be the old-style BSD license with the anti-advertizing clause. It's not compatible with the GPL.

Now, it's arguable that this is "mere aggregation" (git is bulding a mini-distribution), but still..

If it's a problem, we could ask Mr. Astrand for permission:

# Copyright (c) 2003-2004 by Peter Astrand <[email protected]>

-hpa

#14 lore raw

Re: Ship our own copy of subprocess.py

In reply to Junio C Hamano
Quoted 4 lines · * Junio C Hamano ([email protected]) wrote:

I'll be cutting 0.99.7a with this, to help RHEL instalation. Proofreading appreciated.
------------
so people without the latest Python could run merge-recursive.

Sorry I don't think this one will work. It's not going to install compat/subprocess.py, and if it did, I don't think it'd be able to import (how will it find subprocess.py?).

thanks,
-chris

#15 lore raw

Re: Ship our own copy of subprocess.py

Quoted 3 lines · Chris Wright

Sorry I don't think this one will work. It's not going to install compat/subprocess.py, and if it did, I don't think it'd be able to import (how will it find subprocess.py?).

My intent can be found out if you do this:

    $ make
    $ diff -u git-merge-recursive.py git-merge-recursive
    $ grep -C3 GIT_PYTHON_ Makefile
author
#16 lore raw

Re: Ship our own copy of subprocess.py

Quoted 8 lines · Junio C Hamano
Quoted 3 lines · Chris Wright

Sorry I don't think this one will work. It's not going to install compat/subprocess.py, and if it did, I don't think it'd be able to import (how will it find subprocess.py?).

Quoted 6 lines

My intent can be found out if you do this:

    $ make
    $ diff -u git-merge-recursive.py git-merge-recursive
    $ grep -C3 GIT_PYTHON_ Makefile

Seems to work as far as I can tell.

-hpa

author
#17 lore raw

Re: Ship our own copy of subprocess.py

In reply to Junio C Hamano
Quoted 12 lines · Junio C Hamano
Quoted 4 lines · Junio C Hamano

- merge-recursive not requiring 2.4 but checking the result from 'import subprocess', and optionally install its own subprocess.py (I could do this myself but Fredrik could help me);

I'll be cutting 0.99.7a with this, to help RHEL instalation. Proofreading appreciated.

Let me know when you've checked it into the repository, and I'll try running "make rpm" on the affected systems.

-hpa