[gst-devel] Indifference is not an argument!

[Ronald Bultje]

Hey Erik,

[silently removing some user from CC list]

On Mon, 2003-02-24 at 03:39, Erik Walthinsen wrote:
[-specialib/libcolorspace-]
> This puts *two* libraries on the system as a requirement for the default
> 'colorspace' element.  I suspect this will make you twice as likely not to
> use gst-player, but for reasons outlined above, I care enough to assist
> where I can, but I do *not* care enough to design my code in a
> less-than-optimal manner.

After having seen how we handled ffmpeg (which I'm quite happy with),
I'm interested in seeing the same library use of _some_ other
dependencies such as libatomic (assuming we will use that), specialib,
and libcolorspace. 

Admitted, (lcs)colorspace has nothing to do with the gstreamer core,
neither is it a core element (it is an obligatory dependency of one of
our applications, which goes for lots of elements/applications). Still,
I think it would make sense to use (tagged?) CVS versions of projects
like libcolorspace, libatomic etc. just like we do with ffmpeg. The only
problem here is static linking (installing a newer libcolorspace doesn't
update the (lcs)colorspace element), but since A) we release quite often
and B) harddisks are quite huge nowadays, I don't think this is too big
a problem.

Reason is that most, if not any, distribution will include mad,
vorbis/ogg, etc. However, little distributions currently include
libcolorspace - it doesn't have a stable API and a 1.0.x release - which
makes building quite annoying (you could assume distributions to include
it in the future because they have to to get gst-player to work, but
since it's not a 1.0.x release, do we want to depend on that?).
Basically the same problem as with ffmpeg, where we decided to include
it in our releases.

What do others think of this? For some specific plugins, I think it'd be
appropriate to include CVS versions of their code...

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>