On 28. 02. 19 19:29, Adam Williamson wrote:
On Thu, 2019-02-28 at 18:05 +0100, Miro Hrončok wrote:
On 28. 02. 19 16:55, Adam Williamson wrote:
On Thu, 2019-02-28 at 07:51 -0800, Adam Williamson wrote:
On Thu, 2019-02-28 at 06:46 -0800, Tom London wrote:
[root@localhost ~]# sudo dnf --releasever=30
--setopt=module_platform_id=platform:f30 --enablerepo=updates-testing
distro-sync
Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB
00:04
Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B
00:03
Fedora 30 - x86_64 - Test Updates 67 B/s | 257 B
00:03
Fedora 30 - x86_64 - Updates 62 B/s | 257 B
00:04
Fedora 30 - x86_64 7.4 MB/s | 61 MB
00:08
Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB
00:02
Failed to synchronize cache for repo 'virtualbox'
Ignoring repositories: virtualbox
Error:
Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires
libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be
installed
- libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade
repository
- problem with installed package python2-blockdev-2.21-1.fc29.x86_64
https://koji.fedoraproject.org/koji/taskinfo?taskID=33105158 ought to fix this.
More generally, the *flood* of Python 2 dep issues here is something I
was definitely concerned about with the Python 2 retirement policy
explicitly deciding not to say anything about obsoleting Python 2
subpackages :(
I wanted the py3 packages to obsolte the py2, but i was outvoted.
I now manually add those to fedora-obsoelte-packages, but I do it in batches.
I wait for a compose now to make another batch (fora rawhide and f30).
I think where the upgrade fails because the python2 package is a
subpackage and has a version-specific dependency on another subpackage
from the same source package, that other subpackage should obsolete it.
That's what I did for blockdev: python2-blockdev requires libblockdev
of the same version, so to me it makes sense for libblockdev to
obsolete python2-blockdev in builds where python2-blockdev is not
built:
https://src.fedoraproject.org/rpms/libblockdev/c/46c87cc14b2e4783555221d49fbdff7138fb6c0f?branch=master
do you see any issues with that?
I don't. I completely agree with this approach.
According to the package guidelines, you should stick with a hardcoded
version-release here.
However if you update the package in previous Fedoras, you need to raise the
hardcoded version. I consider that a great PITA.
See the entire discussion in https://pagure.io/packaging-committee/issue/754
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
