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

[Peter Maydell <peter.maydell@linaro.org>]

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