common.sh: retrieve linux base path from sysctl when available

[spchamp]

This patch introduces some handling for a custom LINUXBASE under ports, as when there is a corresponding sysctl configuration on the host.

Rationale:

Ports at the site may have been built with a custom LINUXBASE. This pathname may be assumed to match the value of the sysctl mib compat.linux.emul_path

When poudriere is configured without NOLINUX, this patch will use the value stored in that sysctl mib as the base directory for linprocfs mounts. By default, this would be the pathname /compat/linux

If poudriere is configured with NOLINUX, this will use the default value /compat/linux as the LINUXBASE pathname

[spchamp]

I'm now testing the patch as adapted for poudriere-devel-3.3.99.20211130. It has not introduced any build errors for non-linux-c7 ports. Once the build has reached the linux-c7 ports in the schedule, will update if it fails there

[spchamp]

[comment elided]. The second changeset in the pull-source branch was not sufficient.

[spchamp]

I've updated the branch for the pull, now using the linuxbase path in the test before the linprocfs mounts under do_jail_mounts (common.sh)

[spchamp]

I've submitted a similar patch to the FreeBSD issue tracker, for adding this feature as a patch under the poudriere and poudriere-devel releases under ports:

• ports-mgmt/poudriere-devel: Use a dynamic linuxbase from sysctl for linprocfs mounts
• ports-mgmt/poudriere: Use a dynamic linuxbase from sysctl for linprocfs mounts

I've tested the patch out with the poudriere-devel build on FreeBSD 12.3 for the linux-c7 ports.

As a feature, it may be useful for those of us who have built the linux-c7 ports with a custom LINUXBASE and who may be considering any testing for ports under a divergent LINUXBASE (e.g for RPM releases under the CentOS 8-stream repository at any point in time),

[bdrewery]

This is fine. Can you elaborate on why a custom LINUXBASE might be used?

[spchamp]

@bdrewery Ostensibly if anyone was to develop a series of ports of some Linux distribution other than Centos C7, if those ports may be developed in parallel to the Centos C7 ports for liuxulator on FreeBSD, it might need a different LINUXBASE.

Albeit departing from a topic of poudriere development:

Personally, at near the time of sending this pull request, I'd been looking at trying to patch the Centos C7 ports for a parallel set of ports for Cenots 8-stream, which is a rolling release. This might be somehow similar to the Debian 'sid' or 'testing' branches. Albeit, It might be non-trivial to maintain a set of ports for a rolling release as such, though Centos 8-stream might provide a newer set of RPMs.

I'm afraid that the effort got stalled when developing some tools for the dependency tracking across updates in Centos 8-stream.

With the Centos C7 porting as point of reference, then after glancing at the RPM dependencies for the Centos C7 support for linuxulator, I'd though that some additional tools could be developed for use in updating the ports for Linuxulator support onto Centos 8-stream or any other Linux distribution series. For RPM-based distributions, there would be some XML parsing involved for the RPM repository metadata, HTTP of course, and a storage for local state data. I'd started some hacks with Ruby for this purpose, it was difficult to define all the code in a single file though.

Personally, I've started using openSUSE since then, in their Tumbleweed rolling release series, with Bhyve and VirtualBox. More familiar with Ruby scripting now and the structure of an openSUSE distribution, maybe I could revisit those hacks.

Albeit, for a Lightworks (lwks) installation under Linuxulator, even an up-to-date set of RPM-to-linuxulator ports might not be sufficient. For that particular usage case, I was at least able to get the Lightworks GUI to start (and then crash) with some Linuxulator-ready Linux installations outside of the ports LINUXBASE.

Perhaps there may be other usage cases for a Linuxulator port of some newer Linux distribution.