On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard <tstel...@redhat.com> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
