On 5/13/24 07:16, Simon Farnsworth via devel wrote:
On Saturday 27 April 2024 05:34:29 BST Tom Stellard wrote:
Hi,
- Build compat packages (e.g. llvm18) as early as possible. When we package
a new major release of llvm, we create a compat package so that packages that aren't compatible with the new version can still use the old version. In the past, we've waited to introduce the compat packages until the new version of LLVM was ready (typically during the Beta Freeze). However, this proved to be an issue this release for packages the were ready to switch to the compat packages early in the release cycle, but then had to wait for Beta freeze.
- Switch to python-style compat/main packages. In order to make the
packaging more consistent between the main package (e.g. llvm) and the compat package (e.g. llvm18), we would retire the un-versioned dist-git for llvm, and create a new versioned dist-git for each new release (e.g. llvm19, llvm20, llvm21 etc.). We would then designate one of these as the 'main version', and that version would produce binary rpms that look like the current main package (i.e. llvm-libs instead of llvm19-libs).
As a variant on these two ideas, could the main package "Provides" the compat version that it'll become if it's kept around after the main package moves on?
In other words, llvm-libs for LLVM 21 also has a "Provides: llvm21-libs", so that as a consumer of LLVM, I can depend on llvm-libs (meaning I don't really care which version of LLVM, and I'd like the best you offer, or I can depend on llvm21-libs from day 1 if I know that I'm going to need time to move to LLVM 22.
Then, if you do decide to offer llvm21-libs, you can do so with no-one being affected; if you're looking for data on affected packages, you can use dnf repoquery to tell you how many packages depend on llvm21-libs as opposed to llvm-libs.
llvm-libs may not be the best example, because the requires are auto-generated based on the shared object soname, and you aren't supposed to be explicitly requiring them.
For other sub-packages, you can already do
BuildRequires: clang(major) = 18
And it will pull in the either clang or clang18 depending on your Fedora version.
-Tom
- Invert the order of compat/main packages. Instead of having the compat
package be the old version, and the main package be the new version, we would have the compat package be newer and the main package be older. This would allow us to introduce a new version of llvm without impacting other packages that depend on the main version of LLVM.
This, I dislike; the unversioned package should, IMO, be the latest supported by Fedora version, with older versions provided as compat packages where desirable.
If anyone has any feedback on these ideas we'd like to hear it and are happy to discuss these more.
Thanks, Tom