|
From: | Thomas Huth |
Subject: | Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp) |
Date: | Wed, 20 Apr 2022 12:13:54 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
On 19/04/2022 18.24, Daniel P. Berrangé wrote:
On Mon, Apr 11, 2022 at 08:55:19AM +0200, Thomas Huth wrote:On 11/04/2022 01.50, Brad Smith wrote:On 4/10/2022 5:06 AM, Peter Maydell wrote:On Sun, 10 Apr 2022 at 05:51, Brad Smith <brad@comstyle.com> wrote:On 4/8/2022 12:47 PM, Thomas Huth wrote:QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required.I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens.How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMMThey would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I have not looked at the CI bits to see how difficult that would be. Our release cycles are 6 months and the next release will be in the middle of October.OK, thanks for the update, Brad ... so I guess we should defer this patch to QEMU 7.2 (to be released in december) instead? (which would be fine for me - I just wanted to get the discussion started, that's also why I've marked this patch as RFC)Perhaps make 7.1 simply issue a warning message in configure if the bundled slirp is used, to give people a heads up that they'll want to install libslirp-devel soon.
Not sure if people will notice a warning in the output of "configure" ... but I've put some sentences in the ChangeLog here:
https://wiki.qemu.org/ChangeLog/7.0#New_deprecated_options_and_features (which we could repeat for the 7.1 release again) I hope that helps to make people aware... Thomas
[Prev in Thread] | Current Thread | [Next in Thread] |