python and port flavor

I am trying to understand the brief message in the UPDATING file
about port flavor and python.

Am I understanding this correctly?
I should follow these steps for some recent python updates:
pkg delete -f py27-setuptools-36.5.0
cd /usr/ports/devel/py-setuptools
make FLAVOR=py27 reinstall clean

then I notice
===>>> Update py27-Babel-2.3.4 to py27-Babel-2.5.1?
===>>> Update py27-Jinja2-2.9.5 to py27-Jinja2-2.10?
===>>> Update py27-docutils-0.14 to py27-docutils-0.14_1?

I should remove each pkg that needs updating.
Then go to each port directory and run: make FLAVOR=py27 reinstall clean

The message in UPDATING is not clear to me.
 
If you use packages from the official repository exclusively you need to do nothing but update regularly. If you build from ports, currently just ports-mgmt/poudriere and ports-mgmt/synth does have support for FLAVORS.

ports-mgmt/portmaster is broken but some people managed to build then using some manual trick/workaround. Just look for that in the forum.

If you use make you should set the python version you want python stuff to be built, like stated in the UPDATING file, but be aware FLAVORS will no be restricted just to Python stuff in a near future.
 
I have not seen any clear instructions other than what you refer to as "using some manual trick/workaround" in this forum. That is why I posted this thread.

Are there some definitive instructions for people that use portmaster?

BTW, my steps worked for me, but that just adds yet another workaround.
 
I don't understand the confusion. Also Portmaster can easily handle all this, it's not broken when it comes to these issues. See, the whole FLAVOR thing is merely a make specification. Nothing different from, say, BUILD_OPTIMIZED=yes or DISABLE_VULNERABILITIES=yes.

And if you need to use those permanently, then simply define them globally. So: using /etc/make.conf. Problem solved. ((edit): note that I don't recommend setting DISABLE_VULNERABILITIES within /etc/make.conf).

Some people keep calling Portmaster "broken" or "obsolete" which I personally think is funny because all Portmaster basically does is use the standard tools to perform its job. Calling Portmaster broken is - in my opinion - close to calling the standard tools broken, yet... they still fully power the whole process.

The main issue is that you'll need to understand how the vanilla build process works in order to fully appreciate Portmaster. While other tools hide such details for easier use, Portmaster requires that you're at least decently familiar with this 'vanilla' build process, as shown here.

(edit) So the solution is simple: add the new specification to /etc/make.conf.
 
I don't understand the confusion. Also Portmaster can easily handle all this, it's not broken when it comes to these issues. See, the whole FLAVOR thing is merely a make specification. Nothing different from, say, BUILD_OPTIMIZED=yes or DISABLE_VULNERABILITIES=yes.

And if you need to use those permanently, then simply define them globally. So: using /etc/make.conf. Problem solved. ((edit): note that I don't recommend setting DISABLE_VULNERABILITIES within /etc/make.conf).

Some people keep calling Portmaster "broken" or "obsolete" which I personally think is funny because all Portmaster basically does is use the standard tools to perform its job. Calling Portmaster broken is - in my opinion - close to calling the standard tools broken, yet... they still fully power the whole process.

The main issue is that you'll need to understand how the vanilla build process works in order to fully appreciate Portmaster. While other tools hide such details for easier use, Portmaster requires that you're at least decently familiar with this 'vanilla' build process, as shown here.

(edit) So the solution is simple: add the new specification to /etc/make.conf.

thats because you might really like the draconian decisions .
 
I wrote an email to BSDNow asking them to explain this flavor garbage msg in /usr/ports/UPDATING to me.
Some people keep calling Portmaster "broken" or "obsolete" which I personally think is funny because all Portmaster basically does is use the standard tools to perform its job. Calling Portmaster broken is - in my opinion - close to calling the standard tools broken, yet... they still fully power the whole process.
No Portmaster is not broken, someone broke the ports dependency tree and worse left it for the end user to fix!
This stuff should simply not happen, patch your shit brother!
OC
 

# portmaster -a

===>>> Gathering distinfo list for installed ports


===>>> Starting check of installed ports for available updates

===>>> Launching child to update pkg-1.10.2 to pkg-1.10.2_1


===>>> All >> pkg-1.10.2 (1/1)


===>>> Currently installed version: pkg-1.10.2

===>>> Port directory: /usr/ports/ports-mgmt/pkg


===>>> This port is marked IGNORE

===>>> FLAVOR is defined (to py27) while this port does not have FLAVORS.



===>>> If you are sure you can build it, remove the

IGNORE line in the Makefile and try again.


===>>> Update for pkg-1.10.2 failed

===>>> Aborting update


make.conf eh?
 
If you use packages from the official repository exclusively you need to do nothing but update regularly. If you build from ports, currently just ports-mgmt/poudriere and ports-mgmt/synth does have support for FLAVORS.

Where's some good info on how to get poudriere happy with these changes? I'm seeing stuff like this after a ports tree update:

Code:
[00:00:07] ====>> MOVED: security/sshguard-pf renamed to security/sshguard

[00:00:11] ====>> Error: devel/scons depends on nonexistent origin 'devel/py-setuptools@py27'; Please contact maintainer of the port to fix this.

[00:00:12] ====>> Error: textproc/py-sphinx depends on nonexistent origin 'devel/py-Jinja2@py27'; Please contact maintainer of the port to fix this.

[00:00:12] ====>> Error: mail/mailman depends on nonexistent origin 'dns/py-dnspython@py27'; Please contact maintainer of the port to fix this.

[00:00:15] ====>> Error: security/py-fail2ban depends on nonexistent origin 'databases/py-sqlite3@py27'; Please contact maintainer of the port to fix this.

[00:00:17] ====>> Error: Fatal errors encountered calculating dependencies

[00:00:17] ====>> Cleaning up

[00:00:17] ====>> Umounting file systems
 
I am also confused about the new Python flavors approach. Is it still possible to install the same port for two different Python versions, for example, 2.7 and 3.6? When I try this kind of parallel installation using portmaster with a port such as graphics/py-pillow, whichever flavor of the port is currently installed is uninstalled before the new version is installed. Any thoughts? Much appreciated.
 
The question is how can I install devel/py27-setuptools and devel/py34-setuptools and so on. Now I have installed py-setuptools FLAVOUR=py27. The port refuses to install FLAVOUR=py34.
I wasn't two weeks there, don't know to handle this.

The error message if I try to install FLAVOUR=py34
Code:
===>   py27-setuptools-36.5.0 is already installed
      You may wish to ``make deinstall'' and install this port again
      by ``make reinstall'' to upgrade it properly.
      If you really wish to overwrite the old port of py27-setuptools
      without deleting it first, set the variable "FORCE_PKG_REGISTER"
      in your environment or the "make install" command line.
*** Error code 1

I have to update round sixty ports and portmaster refuse
Code:
===>>> Initial dependency check complete for archivers/php56-zlib

===>>> Returning to update check of installed ports


   ===>>> The devel/py27-setuptools port moved to devel/py-setuptools@py27
   ===>>> Reason: Moved to a flavored, generic, version

===>>> Launching child to reinstall py27-setuptools-36.5.0

===>>> All >> py27-setuptools-36.5.0 (54/54)

   ===>>> The devel/py27-setuptools port moved to devel/py-setuptools@py27
   ===>>> Reason: Moved to a flavored, generic, version

===>>> No valid installed port, or port directory given
===>>> Try portmaster --help


===>>> Update for py27-setuptools-36.5.0 failed
===>>> Aborting update
 
Because thge above answers don't seem concudent to me, I'll post the solution that worked for me.
I'm upgrading a machine having two versions of python installed, v2.7 and v3.6. While upgrading mesa-libs, a dependency to llvm pops up, which fails to compile because it has a dependency to python 3.x, but v2.6 is picked first.
It appears to work using this procedure:
- set python and python3 targets in /etc/make.conf:
Code:
DEFAULT_VERSIONS+=python=3.6
DEFAULT_VERSIONS+=python3=3.6
- set PY_FLAVOR on the port command line while running make
cd /usr/ports/devel/llvm80
make -DPY_FLAVOR=3.6


Of course, portupgrade users can persistently set this value in /usr/local/etc/pkgtools.conf in the MAKE_ARGS block, in my case a definition like this fixes the issue:
Code:
MAKE_ARGS = { ...
    'devel/llvm8*' => 'PY_FLAVOR=3.6'
...
}
It may be enough to define the target Python version in less places than I have done, I did not have time to individually try each possibility.
 
Back
Top