Packagers: Notes for June 2025

[ermo]

This post details the latest changes on the packagaging side in AerynOS as of June 2025.

As of this post, you can disregard the repository guidance given in the previous May 2025 post.

Boulder should be kept strictly up to date

If you are not packaging natively from AerynOS, please ensure that you continuosly pull the latest boulder updates from the os-tools git repository, and that you make sure to use the just get-started recipe to build and install the tooling.

New package repository URIs

As part of our infrastructure updates, we have redone our moss-format package repository URI set up to better support CDN caching of packages.

Therefore, please update your system's active package repository to look like this:

Example moss repo list output:

 - unstable = https://cdn.aerynos.dev/unstable/x86_64/stone.index [0]

Example boulder repo list output:

local-x86_64:
  repositories:
    local:
      description: 'system local repo'
      uri: file:///your/homedir/.cache/local_repo/x86_64/stone.index
      priority: 100
      active: true
    volatile:
      description: 'volatile build stream'
      uri: https://build.aerynos.dev/volatile/x86_64/stone.index
      priority: 0
      active: true

The details of the new repository setup you should be using are documented here.

Packaging notes

• PRs must currently target the 2025-05-repo-rebuild branch.
• The cmake v4 update has likely broken the builds for a lot of cmake projects. Generally said projects just need to have their minimum cmake version increased, check the upstream repositories for commits or new versions with the fixes and backport the commits if necessary.
• setuptools has been split out of the python package and is now in python-setuptools. This should be pulled in automatically for builds that use %python_setup or %python_install but builds that use pyproject or other mechanisms to manage python code (like meson) may need python(setuptools) manually added as a builddep.
• The core parts of Python have been split to a new python-libs package, while the python, python3, etc binaries are still in the python package. Generally binary(python) should only be used as a rundep for packages that ship executables (such as binaries in /usr/bin) that have a shebang requiring python. Other packages should depend on python-libs instead.
• Now that the vast majority of toolchain: gnu packages have been fixed to build against clang/llvm there is now a greater desire to keep the repo like that. Please ask for assistance in the packaging channel if you find any packages that seemingly require the GNU toolchain, there are almost always fixes that can be applied to make Clang work.

[dtomvan]

Interesting, if I may ask, why did you guys decide to mostly move away from GCC (while even calling it a "fix")? Is Clang just you guys' more modern choice? I'm sorry if this has been discussed or explained before, I don't really read a lot of PR/issue discussions under this org...

[ermo]

We built the distro with the desire to use clang/llvm by default, which implies that we try to use GCC only where the upstream source supports nothing else and patching it to support GCC is non-trivial.

[sammypanda]

thank you aha, it's difficult to read through everything in matrix ><