Hello Adrián, all, Over time, we might have to support both versions anyway, since not all packages will migrate that quickly. If we go for option 1, then we can do it as follows: Introducing a flag called BR2_PACKAGE_LIBSOUP_3. The flag should have a life-cycle of 3 stages: 1. The newly introduced flag should default to 'false'. All packages which don't support libsoup3 support can add a 'depend on !BR2_PACKAGE_LIBSOUP_3' mark. 2. Over time, we can set the default to 'true', but keep the possibility to use libsoup2 for packages that still lack libsoup3 support. 3. Mark the BR2_PACKAGE_LIBSOUP_3 as legacy. The main advantage of this strategy is that people can start using libsoup3. The Disadvantage is that the new flag has to be maintained for a while. Kr, Thomas Op vr 28 jan. 2022 om 15:13 schreef Adrian Perez de Castro < aperez@igalia.com>: > Hello Thomas, all, > > On Fri, 28 Jan 2022 13:33:32 +0100 Thomas Devoogdt < > thomas.devoogdt@gmail.com> wrote: > > Hello Adrián, all, > > > > I tested indeed libsoup3 against webkitgtk 2.34.4 [1]. By dropping > > -DUSE_SOUP2=ON > > from your commit, I was able to build webkitgtk 2.34.4. > > > > You are right, other packages will have to migrate as well, > > e.g. a GStreamer bump to 1.19.3 is needed [2]. > > > > A quick search learns me that BR2_PACKAGE_LIBSOUP is/can be selected > in/for: > > - BR2_PACKAGE_GMPC (no explicit support mentioned yet) > > - BR2_PACKAGE_GSSDP (support on master branch [3]) > > - BR2_PACKAGE_GUPNP_TOOLS (no explicit support mentioned yet) > > - BR2_PACKAGE_GVFS (no explicit support mentioned yet) > > - BR2_PACKAGE_LIBOSTREE (no explicit support mentioned yet) > > - BR2_PACKAGE_MIDORI (no explicit support mentioned yet) > > - BR2_PACKAGE_WPEWEBKIT (no explicit support mentioned yet) > > > > - BR2_PACKAGE_GST1_PLUGINS_GOOD (starting from 1.19.3) > > - BR2_PACKAGE_GSTD (starting from 1.19.3) > > - BR2_PACKAGE_WEBKITGTK (starting from 2.34.4) > > There is a tracking table for the libsoup3 migration that one of my work > mates > has been maintaining up to date; you can find it here: > > https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 > > For most of the packages from Buildroot that you listed there are patches > filed to their corresponding upstreams. > > The way I see it, there are three possible ways for a migration: > > - Keep both libsoup2 and libsoup3 in the tree, migrate packages to libsoup3 > where possible and where we do not see conflicts (like loading both > versions > in the same process) likely to happen. > > - Replace libsoup2 with libsoup3 *now*, import patches into the Buildroot > tree > for the packages which do not yet have releases compatible with libsoup3. > > - Replace libsoup2 with libsoup3 *later*, once all upstreams of packages > present in Buildroot put out releases that work with libsoup3. > > Personally I tend to think the last option is likely to be the best, to > avoid > confusions and the possibility that people who use Buildroot as basis for > their work get into nasty situations due to both libsoup2 and libsoup3 > being > available. > > Opinions? > > > --- > > [1] > > > https://git.sr.ht/~aperezdc/buildroot/commit/5dc402d58659a35a30afd1de1a8fb8075034f3fc > > [2] > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1044 > > [3] https://gitlab.gnome.org/GNOME/gssdp/-/merge_requests/7 > > > > > > Op vr 28 jan. 2022 om 12:42 schreef Adrian Perez de Castro < > > aperez@igalia.com>: > > > > > Hello Thomas, all, > > > > > > On Fri, 28 Jan 2022 11:59:17 +0100 Thomas Devoogdt < > > > thomas.devoogdt@gmail.com> wrote: > > > > Drop upstreamed patch: > > > > > > > > https://gitlab.gnome.org/GNOME/libsoup/-/commit/5c3d431bdb094c59997f2a23e31e83f815ab667c > > > > > > > > The gnome option was dropped in: > > > > > > > > https://gitlab.gnome.org/GNOME/libsoup/-/commit/3fcaa882c4eb29fd754cdb6dd06195632cb4b52a > > > > > > > > A new "libnghttp2" dependency is added since libsoup 2.99.6 (HTTP2 > > > backend): > > > > > > > > https://gitlab.gnome.org/GNOME/libsoup/-/commit/1a1d29c3114ca86c673d0c0b02a492d0962dcfe8 > > > > > > > > Signed-off-by: Thomas Devoogdt > > > > --- > > > > Config.in.legacy | 6 +++ > > > > .../0001-meson.build-set-c_std-to-gnu99.patch | 40 > ------------------- > > > > package/libsoup/Config.in | 6 +-- > > > > package/libsoup/libsoup.hash | 4 +- > > > > package/libsoup/libsoup.mk | 11 ++--- > > > > package/midori/Config.in | 1 - > > > > 6 files changed, 12 insertions(+), 56 deletions(-) > > > > delete mode 100644 > > > package/libsoup/0001-meson.build-set-c_std-to-gnu99.patch > > > > > > Note that libsoup3 has a new API [1] (and ABI, therefore). Packages > using > > > libsoup2 may not even compile with libsoup3, or may crash at runtime in > > > unexpected ways. > > > > > > You will need followup patches to modify packages that depend on > libsoup > > > to make them use libsoup2. For example in package/wpewebkit.mk we are > > > currently passing -DUSE_SOUP2=ON to CMake, which needs to be changed to > > > OFF. > > > > > > Some packages may not even support yet building with libsoup3. > Therefore > > > we may need to keep the libsoup2 package. This is possible, as both > > > versions > > > are parallel-installable. But then there is one more issue: one cannot > use > > > both libraries in the same process. Which means, for example, if > wpewebkit > > > gets changed to use libsoup3, then GStreamer *also* needs to be changed > > > because both are used inside WebKit. > > > > > > These are all reasons why I have not yet sent patches to do the switch. > > > Probably we want to discuss how to go ahead with the libsoup3 > migration in > > > Buildroot. > > > > > > Cheers, > > > —Adrián > > > > > > --- > > > [1] https://libsoup.org/libsoup-3.0/ch02.html > > > > > Cheers, > —Adrián >