You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@gmail.com> on 2009/05/19 11:38:44 UTC
Why does Subversion 1.6.x require such a recent Python?
I'm trying to get Subversion 1.6.x into RPMforge, and I've got to say,
the requirement for such a recent Python is fairly burdensome. From some
testing, it's apparently only needed for the compilation, not for the
actual operation of Subversion.
I understand how that can happen: whoever wrote those bits has an
up-to-date development environment. But it would be helpful if we could
scale back that requirement a bit: it only occurred with 1.6.0, and
wasn't there for 1.5.6. Ws that really necessary, in revision *35307*
<http://svn.collab.net/viewvc/svn?view=revision&revision=35307>? Can it
be gracefully scaled back to only require 2.3.4, which will ease RHEL 4
compilation considerably?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2310863
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Why does Subversion 1.6.x require such a recent Python?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 20, 2009 at 12:08:01PM -0400, Nico Kadel-Garcia wrote:
> On Wed, May 20, 2009 at 6:33 AM, Stefan Sperling <st...@elego.de> wrote:
> > On Tue, May 19, 2009 at 07:20:22PM -0400, Nico Kadel-Garcia wrote:
> >> The SRPM's have a bunch of small patches, in particular to integrate
> >> sqlite-amalgamation (which is one of the factors I'm trying to resolve).
> >
> > OK. And what exactly is the problem with the sqlite-amalgamation?
>
> RHEL 4 and 5 require the sqlite-amalgamation package, due to their
> out-of-date sqlite. I'm stuffing in hooks to extract the tarball
> referenced by the 'configure' process, and put it at
> 'sqlite-amalgamation'
>
> >> I'd also like to have a gentle word with the smart aleck who put in the
> >> 'without_swig' settings,
> >
> > Where were without_swig settings being put into?
>
> They're in the .spec files. The ones in RPMforge, and many other
> locations, are a bit strange about using such a hook and then ignoring
> it to automatically extract and use the swig-1.3.39 package.
>
> >> then removed all effect of them and simply
> >> included the swig tarball anyway.
> >
> > Which affects you in what way?
>
> It leaves confusing debris in the .spec file. If you're going to not
> use the provided swig component, set up the .spec file so it doesn't
> extract the tarball, don't just skip the final swig 'build' step. That
> can be done with something like this
>
> %prep
> %setup
> # Extract swig on its own
> %{!?_without_swig:%setup -D -T -a 10}
Right. Let me just say that I don't know much about RPMS. I assume
you are trying to use the RPM package building scripts we have
in packages/rpm/, and they have these problems?
If so, and you know how to fix these problems or need help fixing them,
please contact David Summers (you can look up his email address in the
COMMITTERS file). He maintains the RPM packages, and will most likely
accept patches against the RPM build scripts, or otherwise be able to
help you. It wouldn't hurt to put the Subversion developer mailing
list into Cc when you exchange mail with David about this subject.
Thanks,
Stefan
Re: Why does Subversion 1.6.x require such a recent Python?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, May 20, 2009 at 6:33 AM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, May 19, 2009 at 07:20:22PM -0400, Nico Kadel-Garcia wrote:
>> Stefan Sperling wrote:
>> > On Tue, May 19, 2009 at 07:38:44AM -0400, Nico Kadel-Garcia wrote:
>> >
>> >> I'm trying to get Subversion 1.6.x into RPMforge, and I've got to say,
>> >> the requirement for such a recent Python is fairly burdensome. From some
>> >> testing, it's apparently only needed for the compilation, not for the
>> >> actual operation of Subversion.
>> >>
>> >> I understand how that can happen: whoever wrote those bits has an
>> >> up-to-date development environment. But it would be helpful if we could
>> >> scale back that requirement a bit: it only occurred with 1.6.0, and
>> >> wasn't there for 1.5.6. Ws that really necessary, in revision *35307*
>> >> <http://svn.collab.net/viewvc/svn?view=revision&revision=35307>? Can it
>> >> be gracefully scaled back to only require 2.3.4, which will ease RHEL 4
>> >> compilation considerably?
>> >>
>> >
>> > Nico,
>> >
>> > can you elaborate on what problems you are facing exactly?
>> >
>> I can't compile on RHEL 4, even if I rollback the tests for python-2.4
>> or greater to 2.3. Arfrever's reply seems correct that
>
> There seems to be something missing from the mail here.
> You forgot CARRIER LOST or something to that effect :)
Heh. Yes, I'm getting interrupted socially, not by network.
>> The SRPM's have a bunch of small patches, in particular to integrate
>> sqlite-amalgamation (which is one of the factors I'm trying to resolve).
>
> OK. And what exactly is the problem with the sqlite-amalgamation?
RHEL 4 and 5 require the sqlite-amalgamation package, due to their
out-of-date sqlite. I'm stuffing in hooks to extract the tarball
referenced by the 'configure' process, and put it at
'sqlite-amalgamation'
>> I'd also like to have a gentle word with the smart aleck who put in the
>> 'without_swig' settings,
>
> Where were without_swig settings being put into?
They're in the .spec files. The ones in RPMforge, and many other
locations, are a bit strange about using such a hook and then ignoring
it to automatically extract and use the swig-1.3.39 package.
>> then removed all effect of them and simply
>> included the swig tarball anyway.
>
> Which affects you in what way?
It leaves confusing debris in the .spec file. If you're going to not
use the provided swig component, set up the .spec file so it doesn't
extract the tarball, don't just skip the final swig 'build' step. That
can be done with something like this
%prep
%setup
# Extract swig on its own
%{!?_without_swig:%setup -D -T -a 10}
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2332062
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Why does Subversion 1.6.x require such a recent Python?
Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 19, 2009 at 07:20:22PM -0400, Nico Kadel-Garcia wrote:
> Stefan Sperling wrote:
> > On Tue, May 19, 2009 at 07:38:44AM -0400, Nico Kadel-Garcia wrote:
> >
> >> I'm trying to get Subversion 1.6.x into RPMforge, and I've got to say,
> >> the requirement for such a recent Python is fairly burdensome. From some
> >> testing, it's apparently only needed for the compilation, not for the
> >> actual operation of Subversion.
> >>
> >> I understand how that can happen: whoever wrote those bits has an
> >> up-to-date development environment. But it would be helpful if we could
> >> scale back that requirement a bit: it only occurred with 1.6.0, and
> >> wasn't there for 1.5.6. Ws that really necessary, in revision *35307*
> >> <http://svn.collab.net/viewvc/svn?view=revision&revision=35307>? Can it
> >> be gracefully scaled back to only require 2.3.4, which will ease RHEL 4
> >> compilation considerably?
> >>
> >
> > Nico,
> >
> > can you elaborate on what problems you are facing exactly?
> >
> I can't compile on RHEL 4, even if I rollback the tests for python-2.4
> or greater to 2.3. Arfrever's reply seems correct that
There seems to be something missing from the mail here.
You forgot CARRIER LOST or something to that effect :)
> The SRPM's have a bunch of small patches, in particular to integrate
> sqlite-amalgamation (which is one of the factors I'm trying to resolve).
OK. And what exactly is the problem with the sqlite-amalgamation?
> I'd also like to have a gentle word with the smart aleck who put in the
> 'without_swig' settings,
Where were without_swig settings being put into?
> then removed all effect of them and simply
> included the swig tarball anyway.
Which affects you in what way?
Stefan
Re: Why does Subversion 1.6.x require such a recent Python?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
Stefan Sperling wrote:
> On Tue, May 19, 2009 at 07:38:44AM -0400, Nico Kadel-Garcia wrote:
>
>> I'm trying to get Subversion 1.6.x into RPMforge, and I've got to say,
>> the requirement for such a recent Python is fairly burdensome. From some
>> testing, it's apparently only needed for the compilation, not for the
>> actual operation of Subversion.
>>
>> I understand how that can happen: whoever wrote those bits has an
>> up-to-date development environment. But it would be helpful if we could
>> scale back that requirement a bit: it only occurred with 1.6.0, and
>> wasn't there for 1.5.6. Ws that really necessary, in revision *35307*
>> <http://svn.collab.net/viewvc/svn?view=revision&revision=35307>? Can it
>> be gracefully scaled back to only require 2.3.4, which will ease RHEL 4
>> compilation considerably?
>>
>
> Nico,
>
> can you elaborate on what problems you are facing exactly?
>
I can't compile on RHEL 4, even if I rollback the tests for python-2.4
or greater to 2.3. Arfrever's reply seems correct that
The SRPM's have a bunch of small patches, in particular to integrate
sqlite-amalgamation (which is one of the factors I'm trying to resolve).
I'd also like to have a gentle word with the smart aleck who put in the
'without_swig' settings, then removed all effect of them and simply
included the swig tarball anyway.
> this is Arfrever's reply from IRC (slightly edited to remove noise):
>
> <stsp> Arfrever, http://svn.haxx.se/users/archive-2009-05/0693.shtml
> <Arfrever> stsp: I'm not subscribed to that list...
> <stsp> Arfrever, just wanted to show the message to you in case you know
> the reason why 2.4 is required
> <stsp> I can proxy a reply for you to the list if you want
> <Arfrever> stsp: It is required to run autogen.sh or to run tests or to
> build Python bindings.
> <Arfrever> stsp: Python isn't required to build core part of Subversion
> when not regenerating build-outputs.mk.
> <stsp> why can't autogen.sh be run by earlier versions?
> <Arfrever> stsp: We use e.g. sorted() which is new in Python 2.4.
> <Arfrever> stsp: Running autogen.sh is required only after changing
> build.conf.
> <Arfrever> stsp: If somebody patches e.g. configure.ac from the tarball,
> it is sufficient to run `autoconf`.
> <stsp> ok I will send that to the list and see what the reply is
> <stsp> thanks
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2321551
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Why does Subversion 1.6.x require such a recent Python?
Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 19, 2009 at 07:38:44AM -0400, Nico Kadel-Garcia wrote:
> I'm trying to get Subversion 1.6.x into RPMforge, and I've got to say,
> the requirement for such a recent Python is fairly burdensome. From some
> testing, it's apparently only needed for the compilation, not for the
> actual operation of Subversion.
>
> I understand how that can happen: whoever wrote those bits has an
> up-to-date development environment. But it would be helpful if we could
> scale back that requirement a bit: it only occurred with 1.6.0, and
> wasn't there for 1.5.6. Ws that really necessary, in revision *35307*
> <http://svn.collab.net/viewvc/svn?view=revision&revision=35307>? Can it
> be gracefully scaled back to only require 2.3.4, which will ease RHEL 4
> compilation considerably?
Nico,
can you elaborate on what problems you are facing exactly?
this is Arfrever's reply from IRC (slightly edited to remove noise):
<stsp> Arfrever, http://svn.haxx.se/users/archive-2009-05/0693.shtml
<Arfrever> stsp: I'm not subscribed to that list...
<stsp> Arfrever, just wanted to show the message to you in case you know
the reason why 2.4 is required
<stsp> I can proxy a reply for you to the list if you want
<Arfrever> stsp: It is required to run autogen.sh or to run tests or to
build Python bindings.
<Arfrever> stsp: Python isn't required to build core part of Subversion
when not regenerating build-outputs.mk.
<stsp> why can't autogen.sh be run by earlier versions?
<Arfrever> stsp: We use e.g. sorted() which is new in Python 2.4.
<Arfrever> stsp: Running autogen.sh is required only after changing
build.conf.
<Arfrever> stsp: If somebody patches e.g. configure.ac from the tarball,
it is sufficient to run `autoconf`.
<stsp> ok I will send that to the list and see what the reply is
<stsp> thanks
Thanks,
Stefan