2.0 (2025-02-09)¶

Dropping support for end-of-life versions of Python¶

To help improve maintenance work for releng-tool, the utility will now only support versions of Python that have not reached end-of-life. At the time of this release, this includes support for Python 3.9 and later.

Overhaul of Python package processing¶

A significant rework of the management of Python packages has been made. This aims to address the shortcomings on how packages were installed to a target. All Python packages will use Python’s installer module for their install stage. A consistent scheme (similar to posix_home) will be used no matter what platform or distribution releng-tool is running on. This should prevent oddities in the location where Python files are installed into a host, staging or target area.

Developers can override the scheme used by configuring LIBFOO_PYTHON_INSTALLER_SCHEME for a package. The scheme may be configured to native to observe the same results in older versions of releng-tool. The option can also be configured with a supported variant defined by sysconfig or even a completely customized scheme for the project/package.

Additional configurations for Python package includes LIBFOO_PYTHON_INSTALLER_LAUNCHER_KIND, which can be used to tailor what type of package script is generated during an install; as well as LIBFOO_PYTHON_DIST_PATH, which can be used to indicate the alternative location for a dist/ (if required). Note that older Python setup types will require wheel to be available to ensure a proper wheel is generated to be installed.

Related to the above changes, the following improvements have been made to Python packages:

Addressed some installation scenarios where configured package installation prefixes were not applied.
Improve the automatic path registration for host-configured Python packages. This includes both installed scripts and provided Python modules.
Developers can now issue re-install events on Python packages without the process complaining about overwriting files in a target.

Corrections to Git submodule using incorrect revisions¶

While releng-tool has aimed to support the use of Git submodules for Git-based sites, limitations existed in which revisions were used when cloning these modules. When a submodule was processed in previous versions, releng-tool would incorrectly determine the revision based on the most recent release of a target branch instead of the fixed revision tracked by the Git repository (unless a package defined an explicit revision to use).

This releases corrects this by querying the specific revision in the Git repository for the submodule path instead of incorrectly relying on a submodule configuration used for synchronization.

Alternative hash-files for package development revisions¶

A project can define hashes (e.g. libfoo.hash for packages to validate fetched sources. An issue for users operating in a development mode is that configured hash checks may fail if using an alternate revision for a package. This release now supports creating revision-specific hash sets. A package may define a respective libfoo.hash-<rev> file in a package, where <rev> matches the revision being fetched:

└── my-project/
    ├── package/
    │   ├── libfoo/
    │   │   ├── libfoo.rt
    │   │   ├── libfoo.hash
    │   │   └── libfoo.hash-<rev>     <----
    │   ...
    └── releng-tool.rt

Additional control/capabilities on fetching URL sources¶

Two improvements have been added into releng-tool in relation to managing URL sources for a project. The first change adds support for retrying fetch attempts if a transient error is detected. This includes scenarios where a server has indicated a timeout, an internal server error or more. A fetch attempt will now try up to a total of three times before stopping. This aims to improve use cases such as preventing scheduled build failures if a site is only down for a small interval.

A second change related to URL fetching is the introduction of the --only-mirror argument. When the argument is set for a project that also defines url_mirror, all external packages will only be attempted to be downloaded through the configured mirror. This may be helpful for developers wanting to sanity check all expected resources are locally cached.