Re: libgsystem as a shared library
On Wed, Feb 5, 2014 at 11:24 AM, Jasper St. Pierre wrote: 2), since it means that there's no motivation to get stuff into GLib (think of all the churn that happened with GSubprocess). GSubprocess is a *good* example I think because it did successfully end up in GLib. And it was quite worth the extra review time to get it right. Anyways, it's now done: https://git.gnome.org/browse/libgsystem/commit/?id=9363cfc28ede912e2f06d4ccb42a646bb8a4bd2e Built in Continuous: https://git.gnome.org/browse/gnome-continuous/commit/?id=acf8b66418ad10eb0b4c5a80123b64735c2a22db (Look how easy that was =) ) And I started converting my some of my consumers: https://git.gnome.org/browse/hotssh/commit/?id=9836f20a5620c07994582685ea8cc6e5888eb013 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, 2014-02-05 at 11:24 -0500, Jasper St. Pierre wrote: > I mean, copylibs have existed forever, usually by just copying files > around from project A to project B, and back from project B to project > A. Why does structuring this process in a git submodule make it > suddenly illegal in Fedora review? I'm pretty sure it doesn't: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs I've reviewed a couple of GNOME apps using libgd, and every time all I asked in that regards was: 1. the package must filter its automatic provides so that it doesn't end up providing libgd (as it's not a shared library for other packages to use) 2. the package must have "Provides: bundled(libgd)" Which is pretty much what the above guidelines says. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, 2014-02-05 at 11:24 -0500, Jasper St. Pierre wrote: > I mean, copylibs have existed forever, usually by just copying files > around from project A to project B, and back from project B to project > A. Why does structuring this process in a git submodule make it > suddenly illegal in Fedora review? > I cannot speak for Fedora but ARAIK the packagers don't like bundles as if you have security issue with library X you need to track and find all users instead of patching in one place. In addition you might get symbol collisions if you are not careful. > I'm quite opposed to making gsystem a shared library. libgsystem is, > to me, 1) a way to put non-portable Linux-specific or gcc-specific > stuff, 2) a staging ground for GLib components, for projects that want > to get real-world usage before they land in GLib. And I'm sort of not > a fan of 2), since it means that there's no motivation to get stuff > into GLib (think of all the churn that happened with GSubprocess). > > > > On Wed, Feb 5, 2014 at 11:14 AM, Debarshi Ray > wrote: > On Wed, Feb 05, 2014 at 03:21:06PM +, Colin Walters wrote: > > On Wed, Feb 5, 2014 at 10:21 AM, Jasper St. Pierre > > wrote: > > > > > > What was the issue that happened in Fedora package review? > Why > > > doesn't it apply to our copylibs right now, or e.g. libgd? > > > > > I think no one noticed libgd...review only happens on > initial > > submission, there's no real rigorous ongoing process (I > won't comment > > on the sanity of this model now). > > > Packages using libgd often have 'Provides: bundled(libgd)' in > their > spec files. > > Cheers, > Debarshi > > -- > Wearing non-prescription glasses and embracing obscurity > doesn't > necessarily make you a hipster. -- Anonymous > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > -- > Jasper > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
I mean, copylibs have existed forever, usually by just copying files around from project A to project B, and back from project B to project A. Why does structuring this process in a git submodule make it suddenly illegal in Fedora review? I'm quite opposed to making gsystem a shared library. libgsystem is, to me, 1) a way to put non-portable Linux-specific or gcc-specific stuff, 2) a staging ground for GLib components, for projects that want to get real-world usage before they land in GLib. And I'm sort of not a fan of 2), since it means that there's no motivation to get stuff into GLib (think of all the churn that happened with GSubprocess). On Wed, Feb 5, 2014 at 11:14 AM, Debarshi Ray wrote: > On Wed, Feb 05, 2014 at 03:21:06PM +, Colin Walters wrote: > > On Wed, Feb 5, 2014 at 10:21 AM, Jasper St. Pierre > > wrote: > > > > > > What was the issue that happened in Fedora package review? Why > > > doesn't it apply to our copylibs right now, or e.g. libgd? > > > > > I think no one noticed libgd...review only happens on initial > > submission, there's no real rigorous ongoing process (I won't comment > > on the sanity of this model now). > > Packages using libgd often have 'Provides: bundled(libgd)' in their > spec files. > > Cheers, > Debarshi > > -- > Wearing non-prescription glasses and embracing obscurity doesn't > necessarily make you a hipster. -- Anonymous > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, Feb 05, 2014 at 03:21:06PM +, Colin Walters wrote: > On Wed, Feb 5, 2014 at 10:21 AM, Jasper St. Pierre > wrote: > > > > What was the issue that happened in Fedora package review? Why > > doesn't it apply to our copylibs right now, or e.g. libgd? > > > I think no one noticed libgd...review only happens on initial > submission, there's no real rigorous ongoing process (I won't comment > on the sanity of this model now). Packages using libgd often have 'Provides: bundled(libgd)' in their spec files. Cheers, Debarshi -- Wearing non-prescription glasses and embracing obscurity doesn't necessarily make you a hipster. -- Anonymous pgpwheAfUxcQp.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, Feb 5, 2014 at 10:21 AM, Jasper St. Pierre wrote: What was the issue that happened in Fedora package review? Why doesn't it apply to our copylibs right now, or e.g. libgd? I think no one noticed libgd...review only happens on initial submission, there's no real rigorous ongoing process (I won't comment on the sanity of this model now). Now there *should* be a conversation about libgd though here - more generally with any copylib like this we should at least have periodic conversations about them. I'm not qualified to comment on the status of libgd myself though. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, Feb 5, 2014 at 8:48 AM, Richard Hughes wrote: 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. That's a good point. Perhaps there's a simple solution - I just never break API/ABI. That would come at the cost of a potentially uglier API for libgsystem (gs_console_open2() or something) but with the end game in mind of landing in GLib with a nicer API after we've learned from real world experience, that's a fine cost to pay. 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. Unfortunately I personally don't have the luxury for many of my projects of being tightly coupled to the GNOME release cycle. For gobject-introspection, gjs, and hotssh? Sure. For ostree and NetworkManager, I need to be able to run on older systems. 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. You may be right; perhaps I was initially too rigid in saying they couldn't go in GLib because of MSVC/Sun Studio. But you know...Oracle *can* use gcc, and people can cross build from GNU/Linux for win32 instead of using MSVC. Maybe it's fine to just allow app authors to opt in and #include or . I filed a GLib bug, we can discuss there: https://bugzilla.gnome.org/show_bug.cgi?id=723686 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
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 wrote: > On 5 February 2014 11:52, Colin Walters 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On 5 February 2014 11:52, Colin Walters 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
Re: libgsystem as a shared library
On Wed, Feb 5, 2014 at 6:52 AM, Colin Walters wrote: ... but libgsystem helps in the meantime by avoiding code duplication in the meantime, and I will ...work on #ifdefs such that if libgsystem is built against a new GLib, it transparently backends to that, rather than having duplicate implementations. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, Feb 5, 2014 at 5:43 AM, Richard Hughes wrote: One little point tho, how come this can't be installed into GLib proper? First, there's the aspect where libgsystem acts as a "staging ground" where APIs can get real-world use before landing in GLib. Two examples of this: GSConsole gsystem-log.h (systemd journal via a GLib-like API, also acts as a "soft" dependency) 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. Yes, GLib will likely get rebased, but libgsystem helps in the meantime by avoiding code duplication in the meantime, and I will Third, it will contain APIs like the local allocation macros that I don't think should go into GLib. (Although this is admittedly debatable) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On 5 February 2014 09:23, Colin Walters wrote: > My libgsystem ( https://wiki.gnome.org/Projects/LibGSystem ) library is now > copied into sufficient number of modules that I'm considering making it a > real shared library. Cool, I've never really been a fan of submodules, and I'm much more likely to use it in my projects as a shared library. One little point tho, how come this can't be installed into GLib proper? I know it's Unix only, but we've got plenty of other API that's unix specific in the -unix.h headers. Less shared libraries better, etc. Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgsystem as a shared library
Hi, My libgsystem ( https://wiki.gnome.org/Projects/LibGSystem ) library is now copied into sufficient number of modules that I'm considering making it a real shared library. This came up in the context of Fedora package review, but I think it also makes sense from a technical point of view. It'll be another dependency for projects like NetworkManager, but I doubt anyone cares about that. If your build system isn't capable of composing lots of tiny little parts, you probably aren't building GNOME anyways ;) So unless there are any objections, expect to see the first libgsystem standalone release soon, and components presently using it as a submodule should consider switching. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
