On 4/26/24 21:58, Neal Gompa wrote:
On Fri, Apr 26, 2024 at 9:35 PM 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:
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.
These projects are all part of the same git repository upstream.
-Tom
* 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.
--
_______________________________________________
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
