Hi, I'm working on a way to automatically generate Obsoletes tags for Python packages. I.e. for each `python3-foo` package, the automatic generator would create a tag `Obsoletes: python3.10-foo < X-Y` (assuming python3 version is 3.10).
Currently we automatically generate only Provides tags, but not Obsoletes, and when updating to a newer "main" Python version, a user might get file conflicts during the dnf transaction (e.g. files from python3.10-requests would conflict with files from python3-requests). If we have the automatic Obsoletes, `python3-foo` packages would always take precedence over any older `python3.X-foo`, as they should.
To be frank, we don't truly need this in Fedora right now: We only ship alternative Python interpreters (e.g. python3.8, python3.9), but we do not ship additional packages for these alternative Pythons (e.g. we have no python3.9-requests). However, this will be useful for downstream distributors (e.g. CentOS, RHEL, ...), or in cases where somebody builds custom packages for alternative stacks in Fedora.
The downside is that we will have a few thousand (est. 3624 [1]) additional Obsoletes tags in the Fedora repos that are mostly useless. Does anyone see a problem with this? Given the amount of tags already present (e.g. 336 thousand provides [2], 80 thousand requires [3] and 7.5 thousand obsoletes [4]), I think it won't negatively affect anything, but I might be mistaken.
I think it would be useful to have the generator enabled by default, but of course to account for corner cases, I'd implement an opt-out macro (similar to `%python_disable_dependency_generator`). And to make the automatic generator consistent with the manual macros, I would modify the `%py_provides` macro to also generate Obsoletes tags.
What do you think?
[1] repoquery --repo=rawhide --provides -a | grep '^python3.10-' | wc -l [2] repoquery --repo=rawhide --provides -a | wc -l [3] repoquery --repo=rawhide --requires -a | wc -l [4] repoquery --repo=rawhide --obsoletes -a | wc -l
All the best, Tomas Orsava
On Mon, 29 Nov 2021 at 08:04, Tomáš Orsava torsava@redhat.com wrote:
The downside is that we will have a few thousand (est. 3624 [1]) additional Obsoletes tags in the Fedora repos that are mostly useless. Does anyone see a problem with this? Given the amount of tags already present (e.g. 336 thousand provides [2], 80 thousand requires [3] and 7.5 thousand obsoletes [4]), I think it won't negatively affect anything, but I might be mistaken.
That's a question for Fedora Devel, not the Python SIG specifically.
On 29. 11. 21 23:32, Elliott Sales de Andrade wrote:
On Mon, 29 Nov 2021 at 08:04, Tomáš Orsava torsava@redhat.com wrote:
The downside is that we will have a few thousand (est. 3624 [1]) additional Obsoletes tags in the Fedora repos that are mostly useless. Does anyone see a problem with this? Given the amount of tags already present (e.g. 336 thousand provides [2], 80 thousand requires [3] and 7.5 thousand obsoletes [4]), I think it won't negatively affect anything, but I might be mistaken.
That's a question for Fedora Devel, not the Python SIG specifically.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On 12/1/21 14:07, Miro Hrončok wrote:
On 29. 11. 21 23:32, Elliott Sales de Andrade wrote:
On Mon, 29 Nov 2021 at 08:04, Tomáš Orsava torsava@redhat.com wrote:
The downside is that we will have a few thousand (est. 3624 [1]) additional Obsoletes tags in the Fedora repos that are mostly useless. Does anyone see a problem with this? Given the amount of tags already present (e.g. 336 thousand provides [2], 80 thousand requires [3] and 7.5 thousand obsoletes [4]), I think it won't negatively affect anything, but I might be mistaken.
That's a question for Fedora Devel, not the Python SIG specifically.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Based on the feedback from the devel mailing list and from the dnf team, we won't be turning on the automatic Obsoletes in Fedora, only in ELN.
Tomáš
python-devel@lists.fedoraproject.org
-
Elliott Sales de Andrade -
Miro Hrončok -
Tomáš Orsava