FS#75078 - [qemu] current meta pkg arrangement is sub-optimal

Attached to Project: Arch Linux
Opened by Toolybird (Toolybird) - Thursday, 16 June 2022, 04:25 GMT
Last edited by David Runge (dvzrv) - Sunday, 20 August 2023, 21:38 GMT
Task Type Bug Report
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 6
Private No

Details

As per discussion in  FS#74687  this is a proposal to restructure the QEMU meta packages introduced in 7.0.0.

Perusing the forums and reading various comments around the traps, it seems folks expect "qemu-full" to be a superset of "qemu-desktop". This is quite a logical assumption IMHO. Taking it 1 step further, "qemu-desktop" can be a superset of "qemu-base". The new finely grained split pkg arrangement we now have lends itself perfectly to make this happen.

The proposal in simple terms:

"qemu-full" depends -> (qemu-desktop)
"qemu-desktop" depends -> (qemu-base)

We can throw "qemu-emulators-full" into the mix and it then becomes:

"qemu-full" depends -> (qemu-desktop qemu-emulators-full)
"qemu-desktop" depends -> (qemu-base)

The actual make-up of each meta pkg is up for debate but I've included my suggestions in the patch. More on this below.

Proposed arrangement has the advantage of being clean, simple and logical. It also gets rid of "conflicts". All meta pkgs can be installed together side-by-side and users can freely install/remove meta pkgs to suit their needs. All existing "depends" on the meta pkgs continue to work. The existing setup has proven to be a bit awkward and confusing for users.

(everything below is from the other ticket)

> The current setup is done in such a way so that the user is able to install "qemu" (being asked which one)

Yes, that's fine, and this doesn't change under my proposed patch.

> and have a single place where to lookup optdepends

The optdepends tweaking is only a secondary aspect of my patch and was done to address  FS#74805  of which I agree with the sentiments raised therein.

> In your proposed changes you have removed <...> but those components were all part of qemu-headless before

Er no, that's not quite correct. The previous qemu-headless did not drag in mesa and all its associated deps. We have actually regressed here and this is the subject of  FS#74732 . Prior to 7.0.0, there was chatter about qemu-headless already being too fat and not headless enough. I agree which is why I stripped out all the "heads" to make it bare bones and truly headless. For example, my main use case for the headless pkg is libguestfs and for this case the bare bones approach works perfectly. If someone installs qemu-base because they want a headless QEMU but then realise they are missing some bits, say spice, they just need to "pacman -S" the appropriate split pkgs and all is well.

I've re-attached proposed patch to this new ticket.
This task depends upon

Closed by  David Runge (dvzrv)
Sunday, 20 August 2023, 21:38 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with qemu 8.0.4-2
Comment by Toolybird (Toolybird) - Wednesday, 27 July 2022, 05:51 GMT
(Data Trail) Dupes  FS#74732   FS#74805   FS#75046 
Comment by David Runge (dvzrv) - Saturday, 12 August 2023, 09:08 GMT
Please check whether qemu 8.0.4-1 in [extra-testing] fixes this issue for you.
Comment by Toolybird (Toolybird) - Sunday, 13 August 2023, 01:44 GMT
@dvzrv, LGTM. Did some quick smoke testing and all seemed fine. Thank you for implementing this :)
Comment by David Runge (dvzrv) - Sunday, 13 August 2023, 07:44 GMT
@Toolybird: Thanks for checking! :)

I have gone a bit further with the optdepends (previously already) so that the correct optdepends are shown for the respective meta-package.

Loading...