Kubilay Kocak <koobs.free...@gmail.com>:
On 29/10/2013 8:18 PM, Marcus von Appen wrote:
John Marino <freebsd.cont...@marino.st>:
Per IRC conversation with mva, I'm sending python@ a list of ports that
currently don't build in DragonFly poudriere due to ports infrastructure
problems. I have not changed the python default in make.conf. It would
be nice to get Mk/bsd.python.mk (or whatever) fixed so these ports build
in poudriere again. Thanks, John
[broken ports]
There are several more (e.g. graphics/blender), which suffer from the
same issue.
For those, who wonder what is going wrong here:
The interim hack in bsd.python.mk, which always causes ports to pull in
lang/python, if USE_PYTHON[_XXX] is set, is the problem. As some know, I am
currently testing all ports for that problem and am making lang/python a
dependency
on the port, rather than being implicitly set by bsd.python.mk.
Once done, the ports themselves will need to be fixed to use the proper
python version
rather than lang/python, so we can build version-specific packages.
Long story short: No port should depend on lang/python at build and
installation time
as a mid-term goal.
For those with too much free time at their hands: feel free to go
through John's list
and fix the ports to use a proper python version at build time instead
of `python` :-).
Cheers
Marcus
_______________________________________________
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
Thanks for the explanation marcus.
Can we get that list submitted as a PR, with clear instructions on the
fix procedure? Maybe even an example fix to help motivate
Let me create a rough step-by-step example:
1) Use a tinderbox, poudriere or own jail
2) Grab a svn copy of the ports tree
3) Build the problematic port (to build all dependencies flawlessly)
4) Remove the python:${PORTSDIR}/lang/python entry from bsd.python.mk
(around line 583 and line 590)
5) Build the problematic port again (the dependencies ideally should
exist, so they won't cause problems with the missing python symlinks)
4.1) If the port fails due to `python` not being around, fix up the
offending parts:
a) by replacing them with ${PYTHON_CMD} (preferred)
b) by replacing them with python2 or python3
5) If the port builds successfully now, check the USE_PYTHON[_XXX] line:
a) if it uses USE_PYTHON[_XXX]= yes, change it to a proper version
line, either the (only) version it builds with or a version range
(see step 6)
6) Check the installed scripts of the port (stuff that goes into bin/ or
share or so) or other functional parts that might be executed directly
from the shell
a) for the shebang usage of `python`
i) is the port compatible with all python versions?
if yes: great, revise the settings of 5)
if no: duh, revise the settings of 5) and restrict them
ii) change `python` to a proper major or major.minor version
in the script
b) if the scripts are used by other ports as build dependency
i) are they invoked with the correct commands by the relevant port?
e.g `${PYTHON_CMD} depscript.py` instead of `python depscript.py`
or ${LOCALBASE}/bin/depscript.py instead of `python ... `
and so on
ii) fix the dependent port on demand to invoke the scripts correctly
Step 4 to 6 will also be the main tasks, once the lang/python lines has been
officially removed from bsd.python.mk to check for functional issues with
ports, even if the build and install cleanly.
I think this is a perfect opportunity to share the load, and I'll put my
hand up to help.
Some clarity/confirmation included in the PR for the following would
also be great:
- Can these be fixed *now* or is there something that needs to be done
first?
That depends on the ports themselves, their functionality and behaviour as
dependencies for other ports. My infamous example of gtk20 would fit
here quite well.
gtk20 comes with a script gtk-builder-convert (or so), which uses a
simple /usr/bin/env python shebang, which gnome ports rely on (they
just fire up the script at their build stage) - those flaws (which can
happen for nearly every port) are hard to detect and will need manual
intervention here and there to evaluate and fix the issues.
Cheers
Marcus
_______________________________________________
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
