packaging September 2024

packaging@lists.fedoraproject.org

3 participants
3 discussions

Re: Interesting case about conflicts - update that bumps library soname and provides new compat package for old soname
by Miro Hrončok 24 Sep '24

24 Sep '24

On 24. 09. 24 18:37, Adam Williamson wrote: > On Tue, 2024-09-24 at 14:50 +0200, Miro Hrončok wrote: >> On 22. 09. 24 1:00, Adam Williamson wrote: >>> So, arguably, the error here is in the package: clang18 should >>> explicitly conflict with clang < 19, compiler-rt18 should explicitly >>> conflict with compiler-rt < 19, libomp should explicitly conflict with >>> libomp18 < 18.1.7-4 . (currently compiler-rt18 has an explicit >>> conflicts with 'compiler-rt = 18', but that definitely seems wrong; I >>> don't think that could ever be satisfied.) >> >> I think the conflict in clang18 should actually be (clang >= 18 with clang < 19~~). >> >> Anyway, we don't have such conflict in Pythons, we have Obsoletes. >> >> - python3 version 3.13 has an unversioned Obsoletes for python3.13 >> - python3 version 3.12 has an unversioned Obsoletes for python3.12 >> >> Same for various subpackages, such as -libs or -devel. >> >> --- >> >> The Obsoletes exists to upgrade python3.13 to python3 version 3.13 cleanly. >> Surely, this is desired in clang as well? > > I don't believe clang does builds *ahead* like Python does. These are > purely *backwards-compatibility* builds. So when bumping the main > package from 18 to 19, the clang18 package is created to keep things > working which cannot yet work with 19. But at the same time, we can e.g. build clang18 on Fedora 39 today. The Obsoletes approach works both ways. E.g. postgresql also does it that way. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 0

Re: Interesting case about conflicts - update that bumps library soname and provides new compat package for old soname
by Miro Hrončok 24 Sep '24

24 Sep '24

On 22. 09. 24 1:00, Adam Williamson wrote: > So, arguably, the error here is in the package: clang18 should > explicitly conflict with clang < 19, compiler-rt18 should explicitly > conflict with compiler-rt < 19, libomp should explicitly conflict with > libomp18 < 18.1.7-4 . (currently compiler-rt18 has an explicit > conflicts with 'compiler-rt = 18', but that definitely seems wrong; I > don't think that could ever be satisfied.) I think the conflict in clang18 should actually be (clang >= 18 with clang < 19~~). Anyway, we don't have such conflict in Pythons, we have Obsoletes. - python3 version 3.13 has an unversioned Obsoletes for python3.13 - python3 version 3.12 has an unversioned Obsoletes for python3.12 Same for various subpackages, such as -libs or -devel. --- The Obsoletes exists to upgrade python3.13 to python3 version 3.13 cleanly. Surely, this is desired in clang as well? How do the Obsoletes behave in the case your describe: When I have python3 version 3.12 installed (from before we upgraded Python to 3.13) and I run `dnf install python3.12-devel` (when the Python 3.13 upgrade is already in the repos), I get a clean, well-behaved transaction. To reproduce, I tried this: On Fedora 40 (e.g. in a container): 1. (optional) replace dnf with dnf5 to avoid dnf being dependent on Python 2. (optional) dnf5 remove python3-libs 3. dnf5 install python3 (installs python3 3.12.6-1.fc40) 4. dnf --releasever 41 install python3.12-devel In both cases of doing 1-2 and not doing it, the transaction ends up as expected: - python3 3.12 is upgraded to python3 3.13 - python3-libs 3.12 is upgraded to python3-libs 3.13 - python3.12-devel is installed - python3.12 and python3.12-libs are installed as dependencies No transaction errors. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 0

How to proceed if a PR remains open for a long time?
by Ali Gholami 12 Sep '24

12 Sep '24

I opened a PR to bump version of async-timeout https://src.fedoraproject.org/rpms/python-async-timeout/pull-request/4 which solves this bug https://bugzilla.redhat.com/show_bug.cgi?id=2231324 but it didn't get any response and not merged yet. How would you proceed in such situation? Thank you.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2024