On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard <tstellar@xxxxxxxxxx> wrote: > > Hi, > > After each Fedora release we do a retrospective with the LLVM package maintainers > and talk about how we can improve the LLVM packages[1] in Fedora. We've come up > with some ideas for Fedora 41 that we'd like to share to raise awareness and > get feedback. Right now these are just ideas, and we plan to write up a formal > change proposal once we have decided which of these we are going to implement: > > * Spec file merge. We plan to merge the clang, compiler-rt, and libomp packages > in with llvm and have them be sub-packages of the llvm package. This will allow > us to use the build configuration recommended by upstream and also make it possible > to optimize the packages using Profile-Guided Optimizations (PGO). > > * 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. >From other tools and venues and history with gcc and gnutls releaes, I like it. > * 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). > > * 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. My first thought is "don't make me hurt you". So are my second and third thoughts. Please do not leave the nominally obsolete version as the default cnotemporary version, the "main" release should always be the defult. New, pre-release versions should be as short-lived as possible. > If anyone has any feedback on these ideas we'd like to hear it and are happy to discuss > these more. > > Thanks, > Tom > > > [1] LLVM Packages are: llvm, clang, compiler-rt, libomp, lld, lldb, llvm-test-suite, libclc, > llvm-bolt, libcxx, mlir, flang, python-lit, and polly. > -- > _______________________________________________ > 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 -- _______________________________________________ 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
