failure if junking occurs. This was being avoided by adding a BDEP on
pythran to ports depending on cython. Change this to using nojunk
DPB_PROPERTIES instead as the pythran dep is fairly heavy to build
(using gfortran) and this on the path to building rust (via clang
-> py-sphinx -> py-stemmer -> cython) which is indirectly used by
a quarter of the ports tree.
manually; typically this would only be used for building a python extension
that's part of some other distribution in a subdir so this is what you
usually want)
with an old version of py3-bsddb3 installed (otherwise python is blocked).
has to be done this way rather than as quirks due to quirks leaving the
old packages still installed.
lang/python/3 via @pkgpath + @conflict (no quirks entry required
for that, because it is part of the update-set anyway).
glade in 7.8 depended on python 3.12 and in order that upgrades to
-current (and later 7.9) can work, we need to provide an upgrade path
that makes it disappear if installed. listing a port as obsolete does
not do this, it just leaves it installed, along with any packages
which it depends on (i.e. python 3.12 here), resulting in problems
if that causes a conflict.
3.13.10 was a rather massive update and .11 adds a few fixes on top,
some of them for not too terrible security issues:
https://www.python.org/downloads/release/python-31310/https://www.python.org/downloads/release/python-31311/
The annoying bit about this update is that our homegrown expat build
system does not install expat_config.h, which, strangely, is autoconf
results exposed in a public header (next to a few XML_ things). Until
that's sorted in base we get to patch the Python code since the expat
maintainer made the mitigation knobs only available behind some config
knobs, which the new Python code assumes to be enabled.
longer handle py2+3 in the same port
(I'll remove them from existing ports sometime, but probably alongside
a switch to a newer python branch, as a sweep touches a lot of PLISTs)
MODPY_PYBUILD etc) and 3 (which doesn't remove all that much yet, but
when the remaining py3 MODPY_SETUPTOOLS are gone we'll be able to
remove the confusing conditionals around that)
been through enough of a bulk for confidence
(since any python branch switch touches thousands of ports):
- stop using FLAVOR=python3 / MODPY_FLAVOR / etc in py3 ports.
- rename MODPY_EGG_VERSION (which refers to an obsolete packaging
format) with MODPY_DISTV (easier to type and line up in Makefiles)
bumps and adjustments to follow. lots of help from tb@, thanks!
on sparc64 - I tested aarch64) with a few tweaks to allow updating stable.
merge meta/python3 into lang/python/3, there's no need for the separate
empty package any more now that we only have one 3.x version (pkg_add
python%3 will work).
tb's version was OK kmos@
layout alongside the switch to using python 3.11 by default - multiple 3.x
versions haven't been useful enough to be worth the extreme pain to keep
@conflict markers correct now that we have -stable packages to deal with).
looks reasonable to tb@
sthen