Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)

[Thomas Huth <thuth@redhat.com>]

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
>>>> -- PMM
>>>
>>> They 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