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. > * 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 > -- Simon -- _______________________________________________ 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
