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
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by Toolybird (Toolybird) - Tuesday, 15 November 2022, 01:37 GMT
> This is mostly for better packaging on downstream distros like ArchlinuxARM

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.
Comment by Adam (adam900710) - Tuesday, 15 November 2022, 02:31 GMT
Let me be this clear:

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.
Comment by Adam (adam900710) - Tuesday, 22 November 2022, 09:40 GMT
And here is my split PKGBUILDs, which at least the main qemu PKGBUILD builds on both x86_64 and aarch64 natively.

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.
Comment by David Runge (dvzrv) - Sunday, 27 November 2022, 14:59 GMT
> 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.

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
Comment by Adam (adam900710) - Sunday, 27 November 2022, 23:12 GMT
I have already submitted the pull request to do the split:

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.

Loading...