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



## Aknot (Apr 12, 2019)

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


----------



## Wozzeck.Live (Apr 12, 2019)

```
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.


----------



## Hiroo Ono (Apr 12, 2019)

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.


----------



## SirDice (Apr 12, 2019)

Also note /usr/ports/UPDATING:

```
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
```


----------



## hukadan (Apr 12, 2019)

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.


----------



## Minbari (Apr 12, 2019)

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.
> ...


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.


----------



## hukadan (Apr 12, 2019)

Wozzeck.Live said:


> but not for big systems.


Sure, after all synth(1) is just used to build the packages of DragonFlyBSD (30120 packages apparently). So much for the limited number of packages.


----------



## Goober (Apr 15, 2019)

Minbari said:


> OP before updating your software ALWAYS read the /usr/ports/UPDATING.



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.


----------



## gessel (Jul 2, 2019)

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.


----------

