[arch-general] PKGBUILD: replaces array in split packages
Hello, I'm writing a script [1] to update package links on ArchWiki. The script also gives hints on broken/outdated package, e.g. for 'mesa-dri` the hint is "replaced by 'mesa'" (with an appropriate link to the 'mesa' package). I've chosen to only look into the 'replaces' array of the packages, because unlike 'provides', a package can be replaced only by one other package, whereas multiple packages can "provide" the same package. 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. Is this a bug or was my assumption about the 'replaces' array wrong? How would pacman handle the situation where qemu-kvm is supposed to be replaced by libcacard and/or qemu? Thanks for answers, Jakub Klinkovský (Lahwaacz) [1]: https://github.com/lahwaacz/wiki-scripts/blob/master/update-package-template...
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: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/qemu&id=273924889b2563215778521747e0f0eb2e98c038 Then, the package was split going from 1.5.1 to 1.5.2 here: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/qemu&id=3758dddfe4a14cbd6cb5b6ed6ccd0640d169046c I am thinking the replaces() array was missed when the split was created and is a bug that you should report. $0.02, -te [1] https://github.com/qemu/qemu/blob/master/docs/libcacard.txt
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)
participants (2)
-
Jakub Klinkovský
-
Troy Engel