Re: libgsystem as a shared library

["Jasper St. Pierre" <jstpierre mecheye net>]

This is why I liked the subprocess solution. It's just a technically better way to do a copylib.

What was the issue that happened in Fedora package review? Why doesn't it apply to our copylibs right now, or e.g. libgd?

On Wed, Feb 5, 2014 at 8:48 AM, Richard Hughes <hughsient gmail com> wrote:

On 5 February 2014 11:52, Colin Walters <walters verbum org> wrote:
> GSConsole
> gsystem-log.h (systemd journal via a GLib-like API, also acts as a "soft"
> dependency)

Yes, that sounds awesome, but if libgsystem is going to be an "egg"
replacement I would say it's better to just copy and paste the source
files into modules; having an external library indicates some kind of
API and ABI promises, and you don't want to be proxying stuff in glib
for the next decade.

> Second, it contains "backported" API.  An example of this is "GSSubprocess",
> which is now in GLib.  But a lot of my code (and NetworkManager) has to run
> on EL7 for example, which is just GLib 2.36. So it makes sense to have a
> "common backport" area.

As a shared library I'm not sure this argument holds, as a git
submodule it makes a lot of sense. I think putting stuff like this in
glib and surrounding them with I_KNOW_THIS_API_IS_UNSTABLE guards for
an unstable cycle makes a lot of sense while the API is still being
worked on and the early adopters are willing to release tarballs at a
moments notice.

> Third, it will contain APIs like the local allocation macros that I don't
> think should go into GLib.  (Although this is admittedly debatable)

I think they would be awesome in glib itself, and certainly would
encourage developers to start using them.

Richard.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

--
  Jasper