Re: GNOME xdg-app runtime doesn't follow the jhbuild modulesets



On tis, 2016-05-10 at 11:59 -0500, Daniel Espinosa wrote:
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?

There seem to be a fundamental disconnect here wrt why there are
runtimes and how they work.

The reason there is a runtime/app split is *not* to make it easier to
build applications. Bundling is a *fundamental* aspect to how xdg-
app/flatpak works, and you can't expect any app to not bundle a library
or two. This means we need to make the tooling and the upstream modules
make it as easy as possible to do this.

The reason we have a runtime is to share maintainance load and
experience. The most imporant part of the runtime is the core: libc,
openssl, image libraries, opengl, bash, coreutils, compilers (for the
sdk), etc. These are things that require a special kind of developer,
and is not something that you want to force application developers to
know about. We also want to share the burden of security updates, so
that the core stuff gets security updates for all apps without the app
developers having to be on-top of glibc errata every weekend.

But, if a runtime starts getting too much stuff in it then this becomes
a problem. Its slower to build, larger to download, harder to maintain,
it potentially updates more often, and it quickly gets full of old
releases that gets in the way of apps bundling their own newer version.
Runtimes have a much higher guarantee of ABI stability than anything
anyone in the free software world historically have had to deal with,
because they are a long term guarantee that 3rd party binaries will
keep working against it. This means e.g. no or very careful version
updates and bugfix backports. 

Note: The exact stability guarantees can vary from runtime to runtime.
Clearly the nightly runtime builds from git master make no such
guarantees, and the freedesktop.org runtimes likely have a slightly
higher degree of longevity than the regular 6 month gnome runtime
releases.

That doesn't mean that we should not share packaging work for the
dependencies that are bundled with the apps though. We should make it
as easy as possible to reuse each others work. 

This has two sides:
1) If you produce libraries, make it easy to bundle them. For instance,
   make sure you follow colins build-api:
     https://github.com/cgwalters/build-api
   This is pretty automatic if you use automake.
   But also, make sure upstream releases work when built in a 
   different prefix. Make it possible to avoid building things that
   are not being bundled (docs, example apps, cli utils, etc) with
   configure flags.

2) Share xdg-app-builder manifest snippets for the modules so you can
   easily reuse someone elses work. Bastien actually filed a bug 
   recently about adding an include system for the manifests, which 
   would make this easier. We should probably also have a centralized
   place to store these.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a genetically engineered drug-addicted dwarf on the wrong side of 
the law. She's a time-travelling foul-mouthed pearl diver in the witness 
protection program. They fight crime! 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]