Re: LLVM Packaging Ideas for Fedora 41

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

 




Dne 13. 05. 24 v 15:28 Fabio Valentini napsal(a):
On Mon, May 13, 2024 at 3:23 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:

Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):

* 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.


I concur with Neal here.

I we were living in ideal world, we would have just one `llvm` package. Since we are not living in ideal world, it makes sense to have some compat versions. But we should try to get as close as possible to ideal world. Versioning packages by default goes against that goal, because it encourages sticking to some specific version for no particular reason.
For the special case of LLVM, I disagree here. Some projects are just
not compatible with newer LLVM versions until upstream moves first,
and that can take time. So I don't think that counts as "sticking to
some specific version for no particular reason", it's "upstream
doesn't support LLVM X at all yet, they only support LLVM X-1 for
now". I have never seen a Fedora package that uses an LLVM compat
package "for no particular reason".


My point is that we can spent time maintaining llvm00 - llvm99 packages or we can spent time adjusting upstream projects to be compatible with the latest llvm. Maintaining old versions of package might IMHO cost more then adjusting the package to new version.


Vít



Fabio
--
_______________________________________________
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

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

--
_______________________________________________
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