|Summary:||Some FLAVOR related changes|
|Product:||Ports & Packages||Reporter:||Shane <FreeBSD>|
|Component:||Ports Framework||Assignee:||freebsd-python (Nobody) <python>|
|Severity:||Affects Only Me||CC:||ports-bugs|
Description Shane 2017-12-11 11:34:01 UTC
After the FLAVOR change I think there are a couple of things that still need to be addressed that affect concurrent python port installs. As package repos now have two flavours for many python ports, trying to install one using the pkg origin will break the install due to conflicts. 1. USE_PYTHON=concurrent should be considered a default option, or part of implementing flavour, maybe have noconcurrent if a port specifically doesn't need it. 2. Using concurrent still has an issue of conflicting man pages, see bug #220214 as a possibile solution for this. 3. If a port is python3 only then no default scripts exist, only the versioned script is created. See bug #216479. 4. Would it be possible for pkg to record the package flavour so that it can be queried? Maybe even a config option to control what flavours it will install?
Comment 1 Mathieu Arnold 2017-12-11 12:14:27 UTC
4: pkg records the package flavors as an annotation: $ pkg info py27-six [...] Annotations : flavor : py27 3: I'm working on it being "the first flavor" and not "the default version" 2: It needs to be fixed, I have not had time to work on it yet. 1: That is over to python@.
Comment 2 Antoine Brodin 2017-12-11 12:17:59 UTC
I don't think concurrent should be default, it *does* break some ports.
Comment 3 commit-hook 2017-12-11 12:42:53 UTC
A commit references this bug: Author: mat Date: Mon Dec 11 12:41:56 UTC 2017 New revision: 456026 URL: https://svnweb.freebsd.org/changeset/ports/456026 Log: Make USE_PYTHON=concurrent flavors friendly. Before, it would only create the default symlink if the Python version was the default Python version. Change that to if the Python flavor is the default flavor. PR: 224242 Sponsored by: Absolight Changes: head/Mk/Uses/python.mk
Comment 4 Shane 2017-12-12 09:27:29 UTC
(In reply to Antoine Brodin from comment #2) > I don't think concurrent should be default, it *does* break some ports. We are trying to get python ports to build and install for multiple python versions, these concurrent breaks should get resolved as part of the updates to support flavours. My experience with concurrent so far is that most ports only need concurrent added, others need some adjustment for manpages and docs. If concurrent was enabled as a part of defining FLAVOR then USE_PYTHON=noflavors should also disable concurrent for ports it does break. Using pkg install with a port origin (or a partial name match) now finds all available flavours, without concurrent this can lead to install issues that can frustrate users and lead to a bad user experience that will only contribute to complaints. I reported this as a separate issue for pkg - bug #224265