pkg-static: py36-cython-0.29_1 conflicts with py27-cython-0.29 (installs files into the same place)

Aknot

Aknot

Tried to make deinstall clean in lang/cyton but that doesn't work. Any ideas?

6364
 
Code: 
cd /usr/ports/lang/cython
make clean
make FLAVOR=py27 deinstall
make FLAVOR=py36 deinstall

make FLAVOR=py27 reinstall clean
make FLAVOR=py36 reinstall clean

Flavor is the worst thing that FreeBSD port system has created theses last years.
It breaks systematically all automated update process with various problems.

"Portupgrade" tools handles very badly flavor, as it messing up with versions, I don't know for the other port management tools, but this is a real bu...shit, and this is a real loss of time

Sometimes FreeBSD has bad ideas... and this is an awfull idea.

Flavor has been deprecated for QT4/QT5 ports since QT4 has been removed from port, but f...ing flavor still exists for python, and no doubt that with QT6 flavor will reappear again unless port managers have massive demands from user to stop that and to return back to the previous system where each ports were clearly separated.

When you have multiple machines to update, this is just impossible and not acceptable... unless FreeBSD takes care before to update the ports managements tools to handle correctly that.
 
The ports default for python has changed from 2.7 to 3.6. Rebuild and reinstall py27-cython first.
I recommend to do the same for devel/py-setuptools. Then, you should be able to install py36-cython.
See PR 226634 comment #8. I think it is the same problem.
 
Also note /usr/ports/UPDATING:
Code: 
20190410:
 	  AFFECTS: users of python
 	  AUTHOR: antoine@FreeBSD.org
 	
 	  Default version of python was switched to 3.6.
 	
 	  For ports users wanting to keep version 2.7 as default,
 	  add DEFAULT_VERSIONS+= python=2.7 to make.conf
 
I did not realise that the end of Python 2.x was so close (someone even made a count down https://pythonclock.org).
Being the last of the 2.x series, 2.7 will have an extended period of maintenance. Specifically, 2.7 will receive bugfix support until January 1, 2020. After the last release, 2.7 will receive no support.
Click to expand...
 
Wozzeck.Live said:
Since port managers decide to switch the default version to 3.6, maintaining 2.7 as the default is not a good policy as most likely in the future more and more port will be found broken as maintainers will no longer maintain port building versus python 2.7.
In my /etc/conf, regarding python, perl, ruby ... I never set manually a default version, so the system switch automaticallly.

Prior to FLAVOR introduction, Portupgrade tool was perfectly able to handle such migration transparently.
When default perl of default ruby change, there is no porblem.
But... let's say that Python 2.7 and all linked modules will be removed soon, expect that FLAVOR will still exist with Python 3.5.
But it is true that Python 3.5 is not so much used.
Click to expand...
Why are you keep pushing about ports-mgmt/portupgrade when he is using ports-mgmt/portmaster? OP before updating your software ALWAYS read the /usr/ports/UPDATING.
 
Minbari said:
OP before updating your software ALWAYS read the /usr/ports/UPDATING.
Click to expand...

I am not the OP, but I am here via Google because I just ran into this same problem. I want to note that I did read UPDATING before updating, but it doesn't seem to say anything about needing to do anything special. It does note that you have to do something special if you want to keep version 2.7 as the default, but nothing else.
 
Some ports seem to reinstall lang/python27 even if you portmaster -o lang/python36 lang/python27 and, say, portmaster -e py27-setuptools-41.0.1 and then portmaster -Rafd, which is to say that despite the change in default, some ports are still working toward that goal.

The trick above seems to work: rebuild the py27 flavor once and then the py36 flavor should install without conflict..

Rebuilding all py27* ports seems to work well enough. For example on one of my jails, the command I needed was portmaster -Rd py27-Babel-2.7.0 py27-Genshi-0.7_2 py27-Jinja2-2.10 py27-MarkupSafe-1.0 py27-alabaster-0.7.6 py27-asn1crypto-0.22.0 py27-certifi-2018.11.29 py27-cffi-1.11.5 py27-chardet-3.0.4 py27-cryptography-2.3 py27-cython-0.29_1 py27-docutils-0.14_4 py27-enum34-1.1.6 py27-idna-2.7 py27-imagesize-0.7.1 py27-ipaddress-1.0.22 py27-openssl-18.0.0 py27-pycparser-2.18 py27-pygments-2.4.1 py27-pysocks-1.6.8 py27-pystemmer-1.3.0_2 py27-pytest-runner-2.11.1 py27-pytz-2019.1,1 py27-requests-2.21.0 py27-setuptools-41.0.1 py27-setuptools_scm-3.3.3 py27-six-1.12.0 py27-snowballstemmer-1.2.0_1 py27-sphinx-1.6.5_1,1 py27-sphinx_rtd_theme-0.4.3 py27-sphinxcontrib-websupport-1.1.0 py27-sqlite3-2.7.15_7 py27-subversion-1.11.1 py27-typing-3.6.4 py27-urllib3-1.22,1 and, aside from a serf glitch with devel/py-subversion@py27 fixed with a quick portmaster -Rd serf-1.3.9_3, things went smoothly.

Or at least as smoothly as possible on a jail running a Ruby app.
 
You must log in or register to reply here.
Back
Top