Default perl when using pkg binaries

[hobnailed]

Greetings, kind humans.

I'm setting up a scripted jail build (via bastille template), that includes perl5. The contents are largely perl-version-agnostic with no special needs, so my intent had been to use 5.40 which is a year past initial release.

After a pkg install of perl5.40 I was surprised to find that there was no perl in PATH. I looked at https://wiki.freebsd.org/Ports/DEFAULT_VERSIONS, ports/Mk/bsd.default-versions.mk, the perl5 makefile and pkg query '%Fp' and surmise that

• if the perl build identifies itself as default at build time, it does not append its version to its files in /usr/local/bin/
• if it does not identify itself as default at build time, it does append them

I see as well that the repo package for 5.36 which installs without version suffixes is perl5-5.36.

Questions:

• Is perl5 with a hyphen and then the full 5.x version a FreeBSD convention for a "default perl" package without suffixes or am I reading too much into that?
• Is it the default perl formally or informally pegged to (or otherwise to a release in a committed relationship with) a particular quarterly package release (or OS release?)?
• Does the same approach go for the other packages in bsd.default-versions.mk?
  • E.g., do the versions of these packages form a sort of a fixed foundation for the quarterly releases?

Sincere thanks!

 

[SirDice]

The default is 5.40 in main (aka 'latest') and 5.36 in quarterly (2025Q2).

Quarterly:

bsd.default-versions.mk « Mk - ports - FreeBSD ports tree

cgit.freebsd.org

Latest:

bsd.default-versions.mk « Mk - ports - FreeBSD ports tree

cgit.freebsd.org

Is it the default perl formally or informally pegged to (or otherwise to a release in a committed relationship with) a particular quarterly package release (or OS release?)?

No, it's changed in main but because it's not a security or stability issue that change isn't merged to quarterly. When the new quarterly is made (2025Q3) this change will make its way to the quarterly branch. New quarterly branches are made once every three months and they're branched off from 'main'. Then that quarterly branch only gets updates for security or some breaking issues for that 3 month period, in the mean time 'main' will get constant updates on everything. We're nearing the end of 2025Q2, so 'main' and quarterly have diverged quite a bit. At the start of July the new quarterly will be branched off.

There is only one ports tree, all versions on all architectures use the one, and same, ports tree. The ports tree itself (and the changes made to it) isn't linked to any specific FreeBSD version, but individual ports can have limitations. A prime example of this is graphics/drm-61-kmod, this port can only be built on 14.1 or higher. The port is available on 13.x, you just can't build it.

 

[hobnailed]

Thanks for your response SirDice, I appreciate your taking the time to explain and provide an example.

I had not thought about it in terms of the branch model but I see it clearly now. And of course, some of the software in the default-versions scope can easily cohabitate with their other-versioned siblings (like perl), and others would typically demand sovereignty and follow an upgrade-downgrade model (DBs). Approaches abound in open models, but I am thinking that,

• Those who don't care about version at all can let the winds of fortune blow where they will
• Those wanting full control and with a willingness to compile can configure /etc/make.conf for any applicable software and build from ports to be certain about what the results will be
• For my use case, I can choose to install a fixed perl version which is handy metadata for the setup, and script the jail build so that if /usr/local/bin/perl doesn't exist (meaning the installed perl is not the ports default for the pkg branch) it gets symlinked to the version-suffixed executable.