Are there a way to create a org.gnome.Sdk.Extra depending on official org.gnome.Sdk, in order to add less common/used libraries, like GtkSourceView, libgee GXml and others?
I saw options on xdg-app-builder to create SDK, why are they there then?
On Tue, May 10, 2016 at 02:10:35PM +0200, Alexander Larsson wrote:
> The runtime as it stands now is pretty much defined by me from scratch.
> I don't think jhbuild is necessarily a great place to start for
> defining it.
I would have expected that the runtime contains the libraries useful for
apps, that GNOME core depends on and that are hosted on gnome.org (plus
the needed external dependencies so that the runtime is
dependency-closed).
And the jhbuild modulesets provide somewhat such a list.
> First of all, jhbuild is typically used to build the entire desktop,
> and not just the application dependencies. As such it has a lot of
> modules in it that are not useful at all, as they target the "host"
> side of the app/host split.
>
> Secondly, it contains apps and their dependencies. Many such
> dependencies are essentially made only for a few apps, and they are not
> useful or widely used in a larger scope. xdg-app is all about bundling
> such dependencies with the app.
>
> Thirdly, the cost of putting something in the runtime is very high,
> both in terms of maintenance (i.e. we're on hold for security updates
> to it) as well as users (every user in the world have to download and
> update everything in the runtime, even if its not used).
>
> There is also a cost to app author. If a dependency is in the runtime,
> its less work for the app developer, but only if the version in the
> runtime is new enough. If its not, then its just "in the way". This in
> particular hits the app-specific dependencies that are generally rev:ed
> much more often than a runtime.
>
> As for the specific example of GtkSourceView. This is definitely
> something I think e.g. gedit should bundle. It always want the latest
> version, and they are essentially co-developed, so should be easy to
> bundle. Most gnome/gtk-using apps in the world don't use
> GtkSourceView, and its not security sensitive, so I don't see how
> putting it in the runtime would benefit us.
>
> That said, I hope that in the future the release team can take over
> maintainership of the runtime, and for us to have a bit more structured
> approach to what goes in it, and who does so. But we needed to have
> *something* to start with, so for expedience sake I decided the
> details.
Ok.
For me I saw the xdg-app runtime as "here is the GNOME development
platform" (for apps).
It's normal that most GNOME libraries are not used by many GNOME apps,
since there are not a lot of GNOME apps in the first place. But for
example for GtkSourceView, everywhere where GtkTextView is used, the
user probably wants undo/redo support which is provided by
GtkSourceView currently… On Fedora there are approximately 75
applications that depend on GtkSourceView 3 or 2.
Putting e.g. GtkSourceView in the runtime would benefit app authors
because they wouldn't need to update their xdg-apps each time there is a
new GtkSourceView micro version.
But I understand that the runtime maintenance has a cost. But I hope
that building the runtime can be mostly automated when it comes to
updating one library to the latest micro version (e.g. 3.20.1 ->
3.20.2). And if a library is not security sensitive, putting it in the
runtime should not have a high cost (ok the runtime would be bigger to
download, but if the library is anyway used by at least one core GNOME
app which is anyway installed…).
--
Sébastien
_______________________________________________
gnome-os-list mailing list
gnome-os-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-os-list