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 <[email protected]> wrote: > On 5 February 2014 11:52, Colin Walters <[email protected]> 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
