| Summary: | Account request for a new gstreamer-vala package | ||
|---|---|---|---|
| Product: | gstreamer | Reporter: | Evan Nemerson <evan> |
| Component: | account | Assignee: | Thomas Vander Stichele <thomas> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | slomo, stevenvandenbrandenstift, tim |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
PGP key
SSH key |
||
Created attachment 92698 [details]
SSH key
Realized I forgot to include my "preferred account name": nemequ. My real name and e-mail address are the same as this bugzilla account, but to make it explicit: Evan Nemerson <evan@coeus-group.com> I'm not convinced the GStreamer repository is the right place for these bindings. Could you provide some explanation why they can't be maintained within the vala repositories/community much like GLib/Gtk+ are now? (In reply to comment #3) > I'm not convinced the GStreamer repository is the right place for these > bindings. > > Could you provide some explanation why they can't be maintained within the > vala repositories/community much like GLib/Gtk+ are now? To be clear, we have been maintaining them as part of the Vala repository. It has not worked out very well. When we generate bindings for a new version of gstreamer they will sometimes break compatibility with old versions of gstreamer. For example, any changes in the list of C headers results in a VAPI which will work for the new version of gstreamer but not the old version. Issues can also arise when virtual methods get invokers, getters/setters are added to properties, a new method is added which, in GIR terminology, shadows an old one, etc. Basically, any time the code generated by valac changes without the Vala API changing in an incompatible way. While similar issues do exist for GNOME libraries such as GLib and GTK+, the fact that Vala follows the GNOME release cycle tends to reduce problems caused these issues in practice—it's much less likely that someone would be using an outdated GTK+ with a newer Vala than an outdated GStreamer. More specifically, we've never really had to deal with the header issue because all GNOME libraries I can think of have supported single-header for a very long time. The result is that we've stuck with 1.0 for a long time instead of upgrading to 1.1/1.2. We're at the point now where this is starting to be an issue, and we will either need a significant amount of effort to upgrade to 1.2 or simply drop support for 1.0. Those of us who are maintaining the Vala bindings are all in agreement that the it would be best to simply split the gstreamer bindings out into a second package, which is released according to GStreamer's schedule and corresponds with a version of GStreamer, not a version of Vala. This would allow each version to drop support for building against previous versions, though, to be clear, the API would still be backwards compatible. Tim, do you still have reservations about this? Being stuck at 1.0 is causing problems for people using the Vala bindings. After more discussions, it was agreed to WONTFIX this for now. Our goal is still to sync up with the GNOME release schedule in the very near future (fall), and on the GStreamer side there's a strong preference towards keeping the bindings inside or close to vala. Let's revisit this again if it doesn't work out in future for whatever reason. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 92697 [details] PGP key Due to difficulty encountered distributing gstreamer bindings with valac, I would like to create a separate package for distributing Vala bindings. Sebastian and I discussed this a few days ago on IRC and was supportive of the idea.