On Fri, Apr 26, 2024 at 9:35 PM 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: >
Here's some feedback below for each of these ideas. > * 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). > Are these actually released together or are they separately developed and lifecycled? If it's the latter, this would make things much more complex down the road because you'll have to deal with a lot of the weirdness that Nodejs deals with by having to subpackage with different versions and trying to keep the release values coherent so that every NVR of every subpackage is correctly unique. It's not worth it in that case. > * 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. > This is definitely a good idea. It would also mean you can ship the new version faster in Rawhide and use the corpus to properly influence upstream to do the right things before they enter stabilization. Right now, everyone finds out too late and there's never enough time to fix 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). > Ehh? I guess? I don't think this buys us that much. > * 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. > I don't like this idea, it makes things harder to reason about and doesn't actually solve any problems. You also have to do new package reviews for each new version instead of using the compatibility package exception to branch older releases into compatibility packages. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
