FS#76556 - [qemu] Please move qemu-user-static into its own PKGBUILD
Attached to Project:
Arch Linux
Opened by Adam (adam900710) - Sunday, 13 November 2022, 23:24 GMT
Last edited by David Runge (dvzrv) - Sunday, 20 August 2023, 21:41 GMT
Opened by Adam (adam900710) - Sunday, 13 November 2022, 23:24 GMT
Last edited by David Runge (dvzrv) - Sunday, 20 August 2023, 21:41 GMT
|
Details
Description:
This is mostly for better packaging on downstream distros like ArchlinuxARM. qemu-user-static is mostly to run user space programs on a different arch. The most common usage is to chroot into a rootfs for a different arch. (Like chroot into aarch64 rootfs on x86_64 host). Unlike regular qemu, qemu-user-static has very few dependency, and has its own configure/build progress. Although it shares the same qemu code base, it has really nothing similar to the qemu-base/qemu-desktop package groups. Another thing is, recently qemu-user-static failed to build natively on aarch64, thus that build failure cause the whole qemu packages to build, while non-static qemu packages can all be properly compiled. Thus it's better to split the qemu-user-static to a separate PKBGUILD, even this means users need to download the same source twice. Additional info: * package version(s) emu-user-static 7.1.0-10 * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: |
This task depends upon
Closed by David Runge (dvzrv)
Sunday, 20 August 2023, 21:41 GMT
Reason for closing: Won't fix
Additional comments about closing: For Arch Linux there is currently no gain in splitting out the static builds of qemu.
Unsupported downstream distributions have to adapt how they build from source.
Sunday, 20 August 2023, 21:41 GMT
Reason for closing: Won't fix
Additional comments about closing: For Arch Linux there is currently no gain in splitting out the static builds of qemu.
Unsupported downstream distributions have to adapt how they build from source.
This should not be a factor. Arch has *plenty* to do keeping its own house in order. Unsupported downstream distros need to fend for themselves.
No matter if it helps down stream distros, we have a PKGBUILD contains two completely unrelated packages which have:
- Completely different dependency
- Completely different configure/build sequence
- Completely different usage
The only thing they share is the same source code.
Then it seems a valid cleanup to me.
For the qemu packages, they are mostly the same, just with qemu-user-static and qemu-user-static-binfmt removed.
For the qemu-user-static packages, they are way truncated down (less than 150 lines).
Sure, Archlinux doesn't need to bother any downstream projects, but my PKGBUILDs should not cost any extra work except the split itself and can handle both archs well.
Please consider do other projects a favor.
PKGBUILD.qemu-user-static (5 KiB)
while non-static qemu packages can all be properly compiled.
If there is an issue then this should be addressed directly and a patch needs to be applied. Arch Linux ARM tracks its own PKGBUILD for this [1].
If you supply more details here, I'm definitely up for incorporating any required changes so this gets easier downstream.
> Thus it's better to split the qemu-user-static to a separate PKBGUILD, even this means users need to download the same source twice.
This will effectively mean I will have to build and maintain two PKGBUILDs and keep them in sync.
I don't see much of a benefit in that, sorry.
[1] https://github.com/archlinuxarm/PKGBUILDs/blob/708af2879cf6d146e3407aa6c298797beca1f767/extra/qemu/PKGBUILD
https://github.com/archlinuxarm/PKGBUILDs/pull/1959
Upstream qemu guys helped to pinned down the cause (in how glibc builds its static libs).
> This will effectively mean I will have to build and maintain two PKGBUILDs and keep them in sync.
In fact, split PKGBUILDS even allows you to do the update asynchronously.
Especially considering how big/complex the qemu group is.
Splitting out the static part can in fact make testing the newer qemu easier.
Another thing is, the old PKGBUILD is already containing a different configure/build part already.
I doubt if maintaining two different builds is any different than two PKGBUILDs.
The only saving is the source/md5sum lines.