Include python3 metapackage

[mvglasow]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

Python packages on FreeBSD include both the major and minor version in the package name, allowing multiple versions of Python (say, 3.5 and 3.9) to be installed alongside each other, as python35 and python39 are different packages rather than different versions of the same package.

Packages which require any minor version of Python 3 can specify python3 as a dependency, which is a meta-package and will always depend on the Python package for a reasonably current version (python39 for FreeBSD 13).

As of 24.1, OPNsense includes python39 but the python3 meta-package is not installed and not available from the repository.

When developing additional packages (e.g. upcoming plug-ins), this means I have to prepare a different binary package (.pkg) for each Python version available for that system, effectively for every new OPNsense release. In order to install on OPNsense 24.1, the package needs to depend on python39 whereas on OPNsense 24.7 this dependency cannot be satisfied (or will result in the parallel installation of a second Python version, depending on what is available from the repo) and the .pkg needs to be updated to depend on python311.

Describe the solution you like

I would like the OPNsense repo to include python3, so packages that require Python 3 without being particularly picky about a particular minor version can just state that as their dependency. That package can probably be taken from upstream OpenBSD without any modification.

Describe alternatives you considered

• Use make package and makefile to pull in the correct dependency and build the .pkg accordingly. Downsides: this would require me to use a particular toolchain and build on a particular version of a particular OS (whereas now, as long as my package contains no binary code but, say, just scripts and config files, I could use any toolchain I want and even build it on a totally different OS, such as Linux or Cygwin on Windows). Also, I would still need to provide a different .pkg for each version of OPNsense.
• Rename the Python package on OPNsense to include the major, but not the minor version number in its name (python3 instead of python39 or python311). Up to you guys, but I fully understand if you don’t want to maintain this discrepancy from upstream forever.
• Get upstream to rename the Python package in said manner, but I can see why they would refuse such a request, pointing out that the python3 metapackage will solve the issue just as well.
• Get upstream to make their dependencies more flexible, allowing packages to specify dependencies such as python39 OR python311. This would be the way to go for dependencies which are in fact genetically unrelated but nonetheless drop-in replacements for each other (such as curl OR wget), but it is unlikely to happen overnight, if at all. For packages which are just different versions of the same code base but have distinct names in order to allow different versions to coexist, I would then need to provide an exhaustive list of all possible names (python30 OR python31 OR ... OR python311, though any later version will still require me to adapt the package), and upstream will rightfully point out that they already have a solution (in this case, the python3 metapackage).

Additional context

There may be other metapackages in upstream to which the same considerations apply – basically any metapackage which is not in the OPNsense repo but its dependencies are.

[fichtner]

We do offer a python3 link to the appropriate binary. Does that not suffice? If you need to depend on specific Python patches the plugin framework can fill the Python version used.

Cheers,
Franco

[mvglasow]

Interesting, pkg info python3 finds no matching packages, and pkg search python3 just returns one package – python39-3.9.18_2. (On OPNsense 24.1.) What am I doing wrong?

[fichtner]

Looking for a package?

just look for the „binary“:

# which python3

[mvglasow]

I don’t think I’m getting your point:

root@OPNsense:~ # which python3
/usr/local/bin/python3
root@OPNsense:~ # pkg which python3
/root/python3 was not found in the database
root@OPNsense:~ # pkg which `which python3`
/usr/local/bin/python3 was installed by package opnsense-24.1.5_3

So, if I’m building a custom package (with a custom toolchain, which generates a .pkg file with a +MAINFEST in it) which needs Python 3, any minor version: what would the manifest need to specify in deps so the package installs on both OPNsense 24.1 and 24.7? Should I just insert opnsense as a dependency, given that it somehow depends on Python?

[fichtner]

I would just take it as a given fact when operating on OPNsense. The core package is mandatory (pkg vital flag even). As I said all the scripting relies on that python3 link to be set.

[fichtner]

Just reading your question again it would be beneficial to check out how plugins are built as it would probably answer most of your upcoming questions regarding how to integrate something.