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.
Actually, reading Miro's answer and since I spent quite some time thinking about this, maybe I should elaborate more.
I truly think that we should really have one default / rolling non-versioned version of packages and try as hard as we can to keep everything compatible with those versions. This is actually where I see the biggest benefit of distributions. And this is actually also where most of my upstream contributions went.
And if there is need for multiple versions, we should make them parallel installable with the default / rolling version. This would actually allow to have `python` package, which is the default version and likely also `python3.12` if somebody choose to stay with some specific version for specific reason. This would also allow to introduce `python3.13` and keep it for testing forward compatibility and later for backward compatibility purposes.
And no, I don't think about `python` package as a metapackage or so. It would be fully fledged package. Maybe it would be currently the same or very close to the `python3.12` package.
And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me.
Vít
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
