On 2.1.2014 12:37, Petr Viktorin wrote:
On 01/02/2014 08:40 AM, Jan Cholasta wrote:
On 20.12.2013 16:01, Petr Viktorin wrote:
On some platforms, "/usr/bin/python" is Python 3. We require Python 2 so
we should explicitly use /usr/bin/python2.

Xiao-Long, who owns FreeIPA in Arch Linux's AUR [0], wrote a patch for
this issue. I've just updated the patch to current master (so any
breakage this causes is my fault).


[0] https://aur.archlinux.org/packages/freeipa

Why not use distutils to fill in the correct interpreter path

That could be nice to do, at some time, in addition to this change. Do
you want to file a ticket?

IMHO this should be done as part of the above ticket.

instead of hardcoding it?

- Not all of FreeIPA uses distutils. Of course client-install should
probably start using it, but distutils can't touch Makefiles or the spec

That's obvious. We currently run setup.py from the Makefile, not the other way around, and I have no intention of changing that. Some modules are missing setup.py, but that should be easy to fix.

- Having the proper path already available makes development a lot
simpler than having complicated build machinery to call for each change.

I'm not against a sane default value.

- To people unfamiliar with this aspect of distutils, it would not be
obvious why/how the hashbang is changed on install. We need less magic
in our build system, not more.

This is no more magic than anything else done during build. We already use distutils for some of our script, which means these scripts will have their hashbang changed, while others won't. That's far more confusing than using distutils consistently across all of our scripts.

- Relying on distutils makes FreeIPA tied to our build system, which
other distros may or may not want to reuse.

Why would anyone not use our Makefile to build IPA? If there's anything wrong or missing in it, it surely can be fixed. Creating a custom alternative build system does not make sense.

Jan Cholasta

Freeipa-devel mailing list

Reply via email to