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? El may. 10, 2016 11:08 AM, "Sébastien Wilmet" <[email protected]> escribió: > 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/gnome-os-list >
_______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
