Gstreamer-plugins splitting ports .. needs testing and feed back ?

[Michael Johnson]

On Oct 6, 2004, at 3:25 AM, Jose M Rodriguez wrote:

> On Wednesday 06 October 2004 08:43, Michael Johnson wrote:
>> On Oct 6, 2004, at 2:17 AM, Jose M Rodriguez wrote:
>>> El Miércoles, 6 de Octubre de 2004 02:51, Joe Marcus Clarke
> escribió:
> [...]
>>>> I don't really think we need a selector port, though that's
>>>> certainly a possibility.  These plug-ins are pretty useless by
>>>> themselves. They're really only useful if another application will
>>>> load them (yes, you can use the GST command line tools, but how
>>>> many users really do that?).
>>>
>>> Any way you choose, what you can't do is depend on a port with
>>> variable content by the presence of a file/library.  This is the
>>> real thread.
>>>
>>> If this is a real plugin architecture, the ports may detect just
>>> what is
>>> installed.
>>>
>>> I also think that a port selector isn't needed.
>>>
>>> At last here, the safest and easy path seems:
>>>
>>> - Convert multimedia/gstreamer-plugin in a base plugin port with
>>> fixed content.
>>>   * All that 'you really want' in the most basic install.
>>>  The actual bento build must be a good base.
>>>   * All that is critical enough to not safe build out of this.
>>>   * Take off auto detection.
>>>
>>> - Add external ports to the rest.
>>
>> What should the "most basic install" be? which plugins should it  be
>> built with?
>
> A really good question for the port maintainer.
>
> This is more a 'logistic' problem.  If gstreamer have 50 diff plugins
> and you want implement all in a per-port basic, you may have 51 ports
> to maintain, carry on dependencies ...
>
> This is really a big effort that must be take by the port maintainer.
>
> If you can name 20 that allway be in, you have 31 ports.  You can  
> refine
> this in future works.  And you have more chances that this can be
> assumed by the port maintainer.
>


Actually it won't be much different than it is now, just more ports
Please take a look at
Makefile from xvid
and Makefile.common from gstreamer-plugins
http://ahze.net:8080/cgi-bin/cvsweb.cgi/~checkout~/gst-ports/ 
multimedia/gstreamer-plugins-xvid/Makefile?rev=1.1.1.1;content- 
type=text%2Fplain
http://ahze.net:8080/cgi-bin/cvsweb.cgi/~checkout~/gst-ports/ 
multimedia/gstreamer-plugins/Makefile.common?rev=1.11;content- 
type=text%2Fplain

Everything is still in gstreamer-plugins, its setup as master/slave  
ports so you basically only edit one file.

Michael

> So, about the big question, you have really two.
>
> - What must be take-off
> things like arts and some special supports.  Even seems that kde@ must
> be responsible off dependencies on gstreamer-plugins-arts from
> kdemultimedia (as an example).
>
> - What must be in
> first, things that must be problematic out of the base port.
> second, what allways be there.  Take a package from bento, expand the
> tarball and examine the plugins.
>
> If you allready have work done to make ports for every plugin, make the
> gstreamer-plugins port depends on these.  But it must be a fixed
> content port and you must have just only one keyword to select it.
>
>> I've got most of the ports that work with gstreamer-plugins patched
>> for the new gstreamer-plugins and none want the exact same plugins.
>>
>
> You may rework this after the gstreamer-plugins redef.  The ports must
> depend on gstreamer-plugins and the gstreamer-plugins-{extra} they
> really need.  You may make this via keywords if you like.
>
>> Here's what I have so far..
>> gnomemedia2/Makefile:USE_GSTREAMER=     cdparanoia
>> jamboree/Makefile:USE_GSTREAMER+=               esound
>> jamboree/Makefile:USE_GSTREAMER+=               mad vorbis
>> marlin/Makefile:USE_GSTREAMER=  cdparanoia
>> rhythmbox/Makefile:GST_PLUGINS= musicbrainz gnomevfs flac mad
>> rhythmbox/Makefile:USE_GSTREAMER+=              faad
>> rhythmbox/Makefile:USE_GSTREAMER+=              ${GST_PLUGINS}
>> rhythmbox/Makefile:USE_GSTREAMER+=              ${GST_PLUGINS}
>> rhythmbox/Makefile:USE_GSTREAMER+=              vorbis
>> sound-juicer/Makefile:USE_GSTREAMER=    cdparanoia vorbis flac lame
>> tunesbrowser/Makefile:USE_GSTREAMER=    mad
>> tunesbrowser/Makefile:USE_GSTREAMER+=   esound
>> nautilus-media/Makefile:USE_GSTREAMER=  gnomevfs libpng vorbis mad
>> flac
>>
>> Michael
>>
>>>>>> Splitting the port into multiple ports would give us the ability
>>>>>> to package any port.  An obvious example of this is the upcoming
>>>>>> gnomemedia2 which will require CD Paranoia support in gst.
>>>>>>
>>>>>> The major disadvantage to this approach is the overwhelming
>>>>>> administrative burden it adds.  It's a pain to test [py-]libxml2
>>>>>> and [py-]libxslt.  I can't imagine what a gstreamer-plugins
>>>>>> update will do. For that reason, it might be nice to still have
>>>>>> the ability to test-build all plug-ins in a monolithic way
>
> --
>   josemi