Re: Python version dependencies in pkg

From: Dan Mahoney <>
Date: Thu, 29 Sep 2022 19:52:01 UTC

> On Sep 28, 2022, at 23:39, Alexander Leidinger <> wrote:
> Quoting Rainer Hurling <> (from Thu, 29 Sep 2022 06:43:49 +0200):
>> Hi Dan,
>> Am 28.09.22 um 23:01 schrieb Dan Mahoney:
>>>> On Sep 26, 2022, at 20:22, Kevin Oberman < <>> wrote:
>>>> On Mon, Sep 26, 2022, 18:13 Dan Mahoney < <>> wrote:
>>> Okay, so in either the package file, or the repo file, is there a bit that says "whatever is the default" or that explicitly says "if there's not a python, install 3.8"?
>> There is PYTHON_DEFAULT (set to 3.9 ATM) in ports/Mk/ You can override this for example by an entry in /etc/make.conf:
>> DEFAULT_VERSIONS+= python=3.10 python3=3.10

That's ports.  I'm asking about packages.  

>>> I realize I'm asking weird minute questions, but I'm noticing that across our fleet we have some blend of machines that are 3.7, 3.8, and 3.9, and trying to just remove 3.7 attempts to deinstall packages that would work with 3.8.
>> To update from one Python version to another, there are descriptions in /usr/ports/UPDATING, see entry from 20220626

Once again, that's ports.  There's no notes in the package tree about the change in defaults.

>> After changing Python itself (i.e. from 3.7 to 3.9), rebuilding depending py3x-packages will do this version change for you (i.e. from py3.7-* to py3.9-*, ...). It works via the so called flavors.

I'm asking on ports@ because there's not any kind of pkgs@ mailing list.  I feel like I'm not being clear as to why.

> To extend a little bit on that:
> "pkg info | grep py3" will give you a list of ports which are depending on a specific python version. If it lists py37-xxx it means the xxx port depends upon python 3.7. If you then delete python 3.7 pkg will also ask you if it is ok to delete all the py37-* ports.

No, it will give me a list of *packages*, except it won't.

Case in point: bind-tools (which in turn is a dependency of bind9)

# pkg info | grep bind-tools
bind-tools-9.16.27_1           Command line tools from BIND: delv, dig, host, nslookup...
# pkg all-depends bind-tools

The latest version of bind-tools no longer requires python at all (bind 9.18 has rewritten all the utilities in C once again), so I can't just experiment with this.

But trying to do a pkg delete python3.8 attempted to delete bind-tools, and I was looking for the magic incantation that says "without reinstalling bind-tools, how can I re-point it at the python39 variants of that package".  On a box without a ports tree.  Only using pkg.

If the answer is "you really can't unless you run poudriere and tell it to build a different package with a different dependent version of python", then so be it.  But I'd like to be able to install py39-ply, and python39, and have bind-tools not try to deinstall, and instead just re-point itself.  Now, I know this is not the same as a library that can build linked against two ssl's where there are real compile-time/link-time differences.  This is because one particular file in bind-tools is a python script.

If the answer is "some dumb ports will always depend on whatever the default version was on the build farm, so you MUST have those versions installed" that's an answer.

I know ports support "flavors" but there's no py38-bind-tools, which led me to believe there was a looser coupling.

My secondary question: when a pkg is nailed to the "Default" version, does that result in the pkg file itself actually saying 3.8, or just a reference that says "the default was used, but any python will do, but you have to manually edit the pkgdb to update the dependencies".

If I had manually installed py39-ply and python3.9, would bind-tools have still required python3.8 and py38-ply?

> So for a given system with already installed ports it is not simply installing python 3.9 and deleting 3.7. It is also updating all the ports which depend upon 3.7.

Again, that's ports.  My question the whole time has been "how does this knob, specifed in the ports tree, ultimately translate into the pkg tree", where there is no ports tree present and make.conf is not consulted.

I am asking about either fields in the pkg file itself, or in the pkg database.