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 2013/06/22 17:46:41 UTC
svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
I'm working with SRPM packaging of Subversion 1.8.0. So far so good,
but there's an RPM dependency problem for the svnpubsub scripts.
The issue is that there's a stack of init scripts stoed in
tools-doc/server-side/svnpubsub/rc.d That's all well and good, they're
for different operating systems and use things like
/usr/local/bin/pyghon, /usr/bin/bash, and other tools for different
operating systems.
The problem is that, up to now, I've just been grabbing the contents
of "tools-doc" as documents. And because those are *executable*
scripts, they get parsed for dependencies. So the "subversion-tools"
package winds up depending on /usr/local/bin/python, /usr/bin/bash,
and the like.
So, the fix for RPM is easy. From my subversion.spec file:
# Disable binary scripts in svnpubsub, or they get parsed for
# dependencies on /usr/local/bin/python, /usr/bin/bash, and
# package dependencies for other operating systems
find tools/server-side/svnpubsub/rc.d -type l -exec rm -f {} \;
find tools/server-side/svnpubsub/rc.d -type f | sort | while read name; do
chmod a-x "$name"
done
There's also an issue with inconsistent use of ;/usr/local/bin/pyton,
or "/usr/bin/env python", fo the svnpubsub *.py scripts:
# Canonicalize path to python, correctly
for name in tools/server-side/svnpubsub/*.py; do
sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
done
The resulting changes are non-critical, but do clean up RPM building,
and I'd appreciate them.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Daniel Shahaf <da...@apache.org>.
Nico Kadel-Garcia wrote on Sun, Jun 30, 2013 at 19:53:59 -0400:
> On Tue, Jun 25, 2013 at 9:40 AM, Daniel Shahaf <da...@apache.org> wrote:
> > On Mon, Jun 24, 2013 at 03:40:44PM -0400, Nico Kadel-Garcia wrote:
> >> The normal way to handle changing deployment environments is with an
> >> actual configuration or deployment tool, such as autoconf, that sets
> >> the path to the locally detected python and uses *that*.
> >
> > The detected Python (if any) is available in Makefile as $(PYTHON).
> >
> > (I have nothing to say to the rest that wasn't already said somewhere on this
> > thread (perhaps on the dev@ part of it).)
>
> Good point.
>
> Setting it in svnpubsub would then mean *generating* the files to be
> installed form the existing *.py files. Ideall for that, they'd be
> named "script.py.in" instead of "script.py" and built during the
> "make" process.
>
Or make could just change the first line during installation. That way,
people working on svnpubsub won't have to face the overhead of having to
change the .py.in file and generate the .py from it during development.
> But for now, unless the author of the svnpubsub tools cares to rewrite
> them, I think the wrapper script in the SRPM I've written will cover
> the RHEL setups.
Cool.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Jun 25, 2013 at 9:40 AM, Daniel Shahaf <da...@apache.org> wrote:
> On Mon, Jun 24, 2013 at 03:40:44PM -0400, Nico Kadel-Garcia wrote:
>> The normal way to handle changing deployment environments is with an
>> actual configuration or deployment tool, such as autoconf, that sets
>> the path to the locally detected python and uses *that*.
>
> The detected Python (if any) is available in Makefile as $(PYTHON).
>
> (I have nothing to say to the rest that wasn't already said somewhere on this
> thread (perhaps on the dev@ part of it).)
Good point.
Setting it in svnpubsub would then mean *generating* the files to be
installed form the existing *.py files. Ideall for that, they'd be
named "script.py.in" instead of "script.py" and built during the
"make" process.
But for now, unless the author of the svnpubsub tools cares to rewrite
them, I think the wrapper script in the SRPM I've written will cover
the RHEL setups.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Daniel Shahaf <da...@apache.org>.
On Mon, Jun 24, 2013 at 03:40:44PM -0400, Nico Kadel-Garcia wrote:
> The normal way to handle changing deployment environments is with an
> actual configuration or deployment tool, such as autoconf, that sets
> the path to the locally detected python and uses *that*.
The detected Python (if any) is available in Makefile as $(PYTHON).
(I have nothing to say to the rest that wasn't already said somewhere on this
thread (perhaps on the dev@ part of it).)
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Jun 24, 2013 at 12:00 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Branko Čibej wrote on Mon, Jun 24, 2013 at 16:32:56 +0200:
>> On 24.06.2013 11:46, Daniel Shahaf wrote:
>> > Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200:
>> >> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
>> >>> # Canonicalize path to python, correctly
>> >>> for name in tools/server-side/svnpubsub/*.py; do
>> >>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
>> >>> done
>> >> The above will actually break the hook scripts. At best you can use
>> >> "#!/usr/bin/python" in those scripts.
>> > And _that_ will break them on FreeBSD.
>>
>> The discussion is about how to package svnpubsub into an RPM. I don't
>> see what FreeBSD has to do with that.
>
> Changing #!/usr/local/bin/python to #!/usr/bin/python in a script in
> trunk would break that script on FreeBSD.
And using /usr/local/bin/python is broken for everyone else. It's easy
enough to fix in the RPM .spec file, and I've done so. But since
"/usr/bin/env python" is more portable, and in general works quite
well, perhaps being consistent about using it among all the ".py"
files in svnpubsub would be more safe.
The normal way to handle changing deployment environments is with an
actual configuration or deployment tool, such as autoconf, that sets
the path to the locally detected python and uses *that*.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 24, 2013 at 6:08 PM, Branko Čibej <br...@wandisco.com> wrote:
> Please, no-one said anything about changing this on trunk (at least, I
> hope not), so let's please not go on about this.
>
> Though I'll not refrain from mentioning that it's not our trunk's
> mandate to make the scripts work out of the box on FreeBSD, either.
>
There is no one right way to set the #! line that will work on every
platform, it MUST be done at install time.
We don't even try to install the svnpubsub stuff. IMHO it's up to the
packager to deal with the paths if they want to package it. If someone
wants to make it easier to package, IMHO they should be adding it to the
install-tools target. If someone goes to that effort then they should also
deal with the #! paths.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Branko Čibej <br...@wandisco.com>.
On 24.06.2013 18:00, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Jun 24, 2013 at 16:32:56 +0200:
>> On 24.06.2013 11:46, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200:
>>>> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
>>>>> # Canonicalize path to python, correctly
>>>>> for name in tools/server-side/svnpubsub/*.py; do
>>>>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
>>>>> done
>>>> The above will actually break the hook scripts. At best you can use
>>>> "#!/usr/bin/python" in those scripts.
>>> And _that_ will break them on FreeBSD.
>> The discussion is about how to package svnpubsub into an RPM. I don't
>> see what FreeBSD has to do with that.
> Changing #!/usr/local/bin/python to #!/usr/bin/python in a script in
> trunk would break that script on FreeBSD.
Please, no-one said anything about changing this on trunk (at least, I
hope not), so let's please not go on about this.
Though I'll not refrain from mentioning that it's not our trunk's
mandate to make the scripts work out of the box on FreeBSD, either.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Mon, Jun 24, 2013 at 16:32:56 +0200:
> On 24.06.2013 11:46, Daniel Shahaf wrote:
> > Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200:
> >> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
> >>> # Canonicalize path to python, correctly
> >>> for name in tools/server-side/svnpubsub/*.py; do
> >>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
> >>> done
> >> The above will actually break the hook scripts. At best you can use
> >> "#!/usr/bin/python" in those scripts.
> > And _that_ will break them on FreeBSD.
>
> The discussion is about how to package svnpubsub into an RPM. I don't
> see what FreeBSD has to do with that.
Changing #!/usr/local/bin/python to #!/usr/bin/python in a script in
trunk would break that script on FreeBSD.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Branko Čibej <br...@wandisco.com>.
On 24.06.2013 11:46, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200:
>> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
>>> # Canonicalize path to python, correctly
>>> for name in tools/server-side/svnpubsub/*.py; do
>>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
>>> done
>> The above will actually break the hook scripts. At best you can use
>> "#!/usr/bin/python" in those scripts.
> And _that_ will break them on FreeBSD.
The discussion is about how to package svnpubsub into an RPM. I don't
see what FreeBSD has to do with that.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200:
> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
> > # Canonicalize path to python, correctly
> > for name in tools/server-side/svnpubsub/*.py; do
> > sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
> > done
>
> The above will actually break the hook scripts. At best you can use
> "#!/usr/bin/python" in those scripts.
And _that_ will break them on FreeBSD.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Branko Čibej <br...@wandisco.com>.
On 22.06.2013 20:09, Nico Kadel-Garcia wrote:
> On Sat, Jun 22, 2013 at 12:02 PM, Branko Čibej <br...@wandisco.com> wrote:
>> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
>>> There's also an issue with inconsistent use of ;/usr/local/bin/pyton,
>>> or "/usr/bin/env python", fo the svnpubsub *.py scripts:
>> That inconsistency is very intentional: some of the python files are
>> hook scripts, and those use the absolute path of the python interpreter
>> because hook scripts are typically executed with an empty environment,
>> and therefore you cannot assume that "#!/usr/bin/env python" will work.
>>> # Canonicalize path to python, correctly
>>> for name in tools/server-side/svnpubsub/*.py; do
>>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
>>> done
>> The above will actually break the hook scripts. At best you can use
>> "#!/usr/bin/python" in those scripts.
> That's trivial to do, fortunately, and it will work fine in an RHEL
> environment, since "/usr/bin/python" is the default system Python.
I did actually mean "the path of the default Python installation" rather
than /usr/bin/python.
> But I'd trust this claim that it breaks things more if I didn't see
> that "#!/usr/bin/env python" scattered all over the Python hook
> scripts in /usr/share/ on RHEL, including the testserver.py and
> watcher.py in the svnpubsub directory. Only these two scripts have
> "#!/usr/local/bin/python"
>
> commit-hook.py
> revprop-change-hook.py
Only these two files are hook scripts. testserver.py and watcher.py are
development tools and aren't really meant for production use.
> I can see an issue if someone installs, and aliases or sets PATH by
> default, for an alternative Python over in /usr/local/bin/python or
> /opt/Python-2.6/bin/python, and winds up confusing "/usr/bin/env
> python" with an incompatible version. I personally think people who
> get that silly get what they deservice, but I'm happy to be a bit
> safer and do it your way.
Let me reiterate: by default, hook scrips are executed with an empty
enviromnent, which means that PATH is not set and "/usr/bin/env python"
will typically find nothing at all. It has nothing to do with using one
or another Python version. While there is now (in 1.8) a way to set the
environment for hook scripts, it is wrong to assume that administrators
will use that mechanism to set the PATH for hook scripts.
If they do, they can also modify the Python invocation. But it's
definitely not up to the Subversion project to mandate how an admin
wants to set up their server.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Posted by Branko Čibej <br...@wandisco.com>.
On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
> There's also an issue with inconsistent use of ;/usr/local/bin/pyton,
> or "/usr/bin/env python", fo the svnpubsub *.py scripts:
That inconsistency is very intentional: some of the python files are
hook scripts, and those use the absolute path of the python interpreter
because hook scripts are typically executed with an empty environment,
and therefore you cannot assume that "#!/usr/bin/env python" will work.
> # Canonicalize path to python, correctly
> for name in tools/server-side/svnpubsub/*.py; do
> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name
> done
The above will actually break the hook scripts. At best you can use
"#!/usr/bin/python" in those scripts.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com