Created attachment 322469 [details] [review]
build: Don't hardcode #!/usr/bin/python

Review of attachment 322469 [details] [review]:

Looks good to me. Thanks for the patch.

Attachment 322469 [details] pushed as 1b8ad2c - build: Don't hardcode #!/usr/bin/python

(In reply to Ting-Wei Lan from comment #0)
> We can use /usr/bin/env to avoid specifying the full path.

This seems to directly conflict with Debian's python packaging guidelines:

http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter

I guess FreeBSD does not have /usr/bin/python? Why not? There are a ludicrous number of python scripts that assume this exists.

(In reply to Michael Catanzaro from comment #4)
> (In reply to Ting-Wei Lan from comment #0)
> > We can use /usr/bin/env to avoid specifying the full path.
> 
> This seems to directly conflict with Debian's python packaging guidelines:
> 
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-
> interpreter

tools/glib-gtypes-generator.py is not an installed file and it is not part of binary packages that users can download or use, so I think the packaging policy doesn't apply. Debian knows where python is installed on its system, but empathy is not a software specifically made for Debian and it cannot know where python is installed on all systems. If we really don't want to use /usr/bin/env in empathy, the path of python has to be checked in configure and all python scripts have to be generated by configure from .in files.

I think not using absolute paths in sources doesn't cause any problem for packagers. Distributions build packages in clean environments and it is not possible to have an unexpected python version installed in such environment to change the result of the build.

> 
> I guess FreeBSD does not have /usr/bin/python? Why not?

Yes, FreeBSD (and most other *BSD systems) doesn't have /usr/bin/python. /usr/bin is used to store executables provided by the operating system itself. Unlike most GNU/Linux systems, there is a clear separation between the operating system and other softwares. Locations like /usr/bin, /usr/lib, /usr/share, /usr/include should only be used by the operating system, and all packages, which are considered as third-party softwares even if they are installed from the official repository with the official packaging tool, should use a prefix other than /usr. FreeBSD uses /usr/local as the default prefix for packages, but it can be changed if users decide to build all packages they want to use from sources.

> There are a ludicrous number of python scripts that assume this exists.

If the script is made for some specific distributions, or it is packaged in a binary package specifically made for a distribution, then it is fine. If not, it is usually a bug that have to be fixed.

(In reply to Ting-Wei Lan from comment #5)
> tools/glib-gtypes-generator.py is not an installed file and it is not part
> of binary packages that users can download or use, so I think the packaging
> policy doesn't apply.

OK :)

(In reply to Ting-Wei Lan from comment #5)
> If we really don't want to
> use /usr/bin/env in empathy, the path of python has to be checked in
> configure and all python scripts have to be generated by configure from .in
> files.

For installed scripts, I think this is the right solution.

> Yes, FreeBSD (and most other *BSD systems) doesn't have /usr/bin/python.
> /usr/bin is used to store executables provided by the operating system
> itself. Unlike most GNU/Linux systems, there is a clear separation between
> the operating system and other softwares. Locations like /usr/bin, /usr/lib,
> /usr/share, /usr/include should only be used by the operating system, and
> all packages, which are considered as third-party softwares even if they are
> installed from the official repository with the official packaging tool,
> should use a prefix other than /usr. FreeBSD uses /usr/local as the default
> prefix for packages, but it can be changed if users decide to build all
> packages they want to use from sources.

Hm, interesting. I'm amazed you have an operating system without python. :o

(In reply to Michael Catanzaro from comment #6)
> (In reply to Ting-Wei Lan from comment #5)
> > Yes, FreeBSD (and most other *BSD systems) doesn't have /usr/bin/python.
> > /usr/bin is used to store executables provided by the operating system
> > itself. Unlike most GNU/Linux systems, there is a clear separation between
> > the operating system and other softwares. Locations like /usr/bin, /usr/lib,
> > /usr/share, /usr/include should only be used by the operating system, and
> > all packages, which are considered as third-party softwares even if they are
> > installed from the official repository with the official packaging tool,
> > should use a prefix other than /usr. FreeBSD uses /usr/local as the default
> > prefix for packages, but it can be changed if users decide to build all
> > packages they want to use from sources.
> 
> Hm, interesting. I'm amazed you have an operating system without python. :o

A clean installation of FreeBSD doesn't have python. NetBSD and OpenBSD also don't include python in their base systems. Boot scripts are written in shell, so it can boot without perl and python. This doesn't mean most FreeBSD systems don't have python installed. It simply means the python package installs /usr/local/bin/python instead of /usr/bin/python.