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
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
