Re: LLVM Packaging Ideas for Fedora 41

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux