On 13.02.15 at 19:40, Troy Engel wrote:
On Fri, Feb 13, 2015 at 5:21 PM, Jakub Klinkovský <j.l.k@gmx.com> wrote:
Or at least I thought so - it appears that both qemu and libcacard have qemu-kvm in their 'replaces' array. In this case, it's because qemu is a split package (qemu + libcacard) and the replaces array is defined globally in the PKGBUILD, not per-package.
I am not familiar with qemu, however it appears to be a packaging bug in qemu. The qemu package does not depend on libcacard, and libcacard does not depend on qemu; based on the readme[1] it sure looks like this just happens to be another library developed by the same team which can be used with qemu for added features.
Looking at the qemu PKGBUILD, it seems like that replaces('qemu-kvm') belongs in package_qemu() and not in the global definition. The replaces() was added in the commit going from 1.2.x to 1.3.x when the package was not split:
Then, the package was split going from 1.5.1 to 1.5.2 here:
I am thinking the replaces() array was missed when the split was created and is a bug that you should report.
Thanks, I've reported the bug for qemu: https://bugs.archlinux.org/task/43814 As a side note, qemu in fact depends on libcacard, but libcacard alone does not replace qemu-kvm. I've also tested what pacman would do in this situation with a dummy package, and it prompts for all packages replacing qemu-kvm: :: Starting full system upgrade... :: Replace qemu-kvm with extra/libcacard? [Y/n] :: Replace qemu-kvm with extra/qemu? [Y/n] Answering Yes and then No would lead to only libcacard being installed. So I guess it is theoretically possible to have multiple packages replacing the same package, but these situations are probably unwanted. -- Jakub Klinkovský (Lahwaacz)