[Delta] Managing GStreamer and dependencies

[textshell-I1QKlO at neutronstar.dyndns.org]

On Thu, Nov 13, 2008 at 01:33:18AM -0800, Justin Karneges wrote:
> The introduction of GStreamer as a dependency complicates things.  Psi is 
> generally known as being easy to build.  If you were even slightly 
> inconvenienced by something like QCA, then GStreamer will be a living hell.

Well psi doesn't work without qca and qca for a long time wanted to be
installed into a system location (at least one file).
On the other hand gstreamer would be optional and hopefully be able to
build to a seperate prefix on linux. And yes, for Win32 and OS X prebuild
packages is what would make life easy for people building psi. It's not
like most people following psi development likly want to hack on gstreamer.


> 
> When I first started looking at GStreamer awhile back, I gathered the source 
> of all of the dependencies we needed, converted all the builds from autotools 
> to qmake, and packed it all into one bundle.  The intent was to make it 
> possible for people compiling Psi to easily build GStreamer as well, without 
> any fuss.  Of course, this was also not very maintainable.
> 
> Thinking about it now, I guess it's not really that important for everybody to 
> be compiling GStreamer.  It's easy enough to get GStreamer for Linux with apt 
> or whatever, and for Windows and Mac it may be enough to distribute binaries.  
> Fortunately there are already efforts on the binaries front, such as 
> Collabora's OABuild.

Yes, if psimedia doesn't depend on a too recent gstreamer release just
taking it from the distro should work fine. Again Win32 and OS X users seem
to prefer binaries too, just that we would have to link to good binary+dev
packages or create them.


> 
> My tentative plan, then, is for the Delta project to "officially" provide 
> GStreamer binaries for Windows and Mac, possibly leveraging an upstream 
> binaries source.  Not every GStreamer module will be included, just the ones 
> that we need.

I'd say delta should only provide binaries as long as there is no good
other source. 

> 
> An open question is how we should distribute the PsiMedia provider plugin.  I 
> suspect some distributions may want to split out the plugin, so that a 
> non-multimedia-enabled Psi is still possible.  For example, I could easily 
> see Debian having 'psi' and 'psi-plugin-media' packages (where the second has 
> all the GStreamer dependency hoopla).  However, just because distributions 
> might like to make two binary packages doesn't mean we necessarily want to 
> offer two source packages.
> 
> What I figure we could do is put everything in one source package, and if 
> GStreamer is detected by configure then you'll get both Psi and the plugin.  
> You could then create two distro packages out of these results if you wanted.  
> Building just Psi would be possible of course.  Additionally, we could have 
> a --media-plugin-only option to configure which lets you build /just/ the 
> plugin.  This might be useful for Gentoo, if you already have Psi built but 
> now you want to emerge just the plugin.

If a distro wants to ship one version with the feature and one without they
can in the worst case build to different version, and they do that often
too. But sure it's easier if they only need to build once and can split
into two packages by putting some files into a seperate package.

Also i agree to remko, that this isn't the most pressing issue for now. If
jingle voice starts to work, we can look more into this and maybe split the
work a bit among us too, splitting the core coding seems a lot harderr.

 - Martin