misc: Conditionally port to libsoup3 #4582
Conversation
|
I updated the branch. It behaves differently now:
This depends on hughsie/appstream-glib#421 , for the libsoup3 build. That change is not needed for the libsoup2 build. |
|
Richard mentioned on the appstream-glib merge request that a soname version should be probably changed too. That would involve also the .pc file name change, thus both versions can be installed at the same time on a single machine. What do you think? |
Some of the required changes depend on the fact whether you want to allow installing both builds in parallel. If not, then a simple soname version bump for libsoup3 build is perfectly fine. |
Please see the discussion in hughsie/appstream-glib#421 , the parallel install-ability is not a requirement, thus the later can be done. I did not get how the soname version is constructed (or better how it should be changed) in the configure.ac, thus I did not update the merge request with such change. |
As the time moved, I realized this was not a good idea, it should rather default to soup3 and have an option |
I would actually remove the libsoup2 support. flatpak is not a library that would cause issues with porting other applications, so there's no reason to retain compatibility with libsoup2. |
(a) Don't we want to be able to backport Flatpak to ye olde LTS distributions (Debian, Ubuntu LTS, RHEL), so that users of LTS distributions can use Flatpak to run new apps? (b) flatpak is a library (among other things), gnome-software uses it. |
No strong preference from me.
Hm, good point, I forgot about libflatpak. OK, Milan's existing plan seems fine, then. |
|
What is the actual discussion that needs to be resolved here to proceed? Parallel-installability of something? |
Build for libsoup3 by default. Use --with-soup2 configure option to build with libsoup2 instead. The libsoup API version is exposed in the flatpak.pc file as well, thus the library users can check they use the same libsoup API version as the flatpak library.
I rebased the merge request against the latest master.
It depends what the decision will be. Having the distro always use one or the other libsoup version would be really much easier than to maintain two versions. |
|
I consider it s very niche thing distro would need parallel libflatpaks with soup2 and soup3 at the same time. Seems not worth supporting upstream. @smcv any thoughts? |
|
If distro needs it, it can be supported through downstream patching like libcurl-gnutls anyway. |
|
It depends on how much software is using libflatpak. If you do not have many dependencies, then it's not a big deal. But if you do, a distro may find it effectively impossible to upgrade if it's not parallel-installable. |
|
I feel there is a potential risk for updates here. Suppose you're using gnome-software to update libflatpak, and your gnome-software links to libflatpak. If the libflatpak update gets updated, and g-s not, and the new lfp uses soup3, then the gnome-software will fail to start the next time as it links in both soup2 and soup3. I wonder if it is possible to avoid this though? Maybe distros really just have to be very careful. Also, what is the libostree approach to soup3? It seems to be soup2 only. I guess you can avoid conflict there by linking it to libcurl instead. Should we do that in flatpak too? I really want to avoid having the libflatpak soname dependent on a build option though. Especially for a technically internal dependency. |
I do not think you can avoid partial updates (users updating only smaller parts, not the whole distro/all packages at once). The distros still should be careful, that's true, though it was always like this. The trick in the build time is to verify the correct libsoup version is used for the known dependencies. An example is here:
That's an option too. |
|
Honestly, I think the correct solution here is to drop soup for libcurl. We rely on ostree that uses libcurl anyway (on most distros i think, and at least its not moving to soup3). This way we avoid libflatpak makign other things unstable by getting conflicting soup3/2 in the same process. I don't actually think this is a lot of work even, we can steal the code from ostree, and the http code is quite centralized in the codebase. |
|
Is there some reason why libsoup would be preferrable here? I recall some comments about proxy support differences. |
I've been told libcurl does not support web proxy autoconfig (so presumably it does not use libproxy?). Presumably some businesses that are currently using flatpak would not be able to do so anymore? |
|
To be fair, if RHEL uses ostree with libcurl, it might not that much change current situation. (I was only able to find out Fedora spec which proves Fedora uses curl with ostree but not RHEL) |
|
Well, if you need autoconfig, then you need to build ostree with soup, and since that only does soup2 we can't make flatpak soup3. So, either port both to soup3 (which still has potential conflicts with other libs) or flatpak to curl. It seems like curl is the better choice atm. |
|
And yes, rhel ostree is curl. |
For what it's worth, the same as Fedora. Furthermore, the .spec file claims it uses libsoup only for internal tests and Nonetheless, this is Fedora. It looks like the ostree itself can use libsoup instead of curl too (it's a build-time option, if I read it correctly), thus using curl can be safer for flatpak libs. It cannot be safer for the flatpak libs users, because they still need to take care of the all flatpak libs dependencies to use the same libsoup version. |
|
It can definitely be safer. It is one less moving part for flatpak lib consumers when migrating to libsoup3. |
|
Please consider supporting libsoup3 as we (in the company) are forced to use a pac proxy which is not supported within curl. Thus this change would cause serious flatpak problems. |
|
@janbrummer Well, that would require ostree to support soup3 too. I'm not sure that is happening. I wouldn't mind if we supported both as a compile option, but again, given that most people build ostree w/ curl I think that is the best approach for default. |
|
There is a pull request for ostree here: ostreedev/ostree#2547 |
|
As one of the people maintaining flatpak build as part of freedesktop-sdk project curl option would definitely be worth considering if it existed. |
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
|
The preparatory work for curl support is here: |
As discussed in flatpak#4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
As discussed in #4582 we want ot use GUri for soup3, and if we want to use libcurl we might as well also use it to avoid complex ifdefs, as we're linking to it already via glib. This imports a subset of GUri for older versions of glib.
|
I suppose this should be closed in favor of the #4943, right? |
The `soupapiversion` variable had been added in [1], but it did not land yet and possibly never will. The flatpak library can be built with libcurl instead, which should be detectable somehow too. As there is currently no way to know what libsoup version the flatpak library had been built with, if any, drop the check in the build script. Closes https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1877 [1] flatpak/flatpak#4582
Just a note, if this is still relevant, there should be made a change to indicate in the .pc file that the flatpak library had been built with libcurl instead, thus any |
|
FWIW, the ostree PR was merged and was released in ostree v2023.3. In case anyone cares to keep working on a soup3 backend for flatpak. |
Use --with-soup3 configure option to build with libsoup3. If not specified,
uses libsoup2. The libsoup API version is exposed in the flatpak.pc file
as well, thus the library users can check they use the same libsoup API
version as the flatpak library.