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

[Michael Johnson]

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ó:
>> On Tue, 2004-10-05 at 08:04, Jose M Rodriguez wrote:
>>> On Tuesday 05 October 2004 04:07, Joe Marcus Clarke wrote:
>>>> On Mon, 2004-10-04 at 21:51, Adam Weinberger wrote:
>>>>>>> (10.04.2004 @ 2143 PST): Michael Johnson said, in 2.0K: <<
>>>>>>
>>>>>>   - Figure out which ports use gstreamer-plugins and which
>>>>>> plugins each needs
>>>>>>
>>>>>>> end of "Gstreamer-plugins splitting ports .. needs testing
>>>>>>> and feed back ?" from Michael Johnson <<
>>>>>
>>>>> I'd be interested in seeing the results of this sooner rather
>>>>> than later; I still don't understand why this is necessary. For
>>>>> anything that requires a libmad backend to gstreamer, we could
>>>>> just test for something and make a ${BROKEN} error or
>>>>> something.
>>>>
>>>> That works when ports are being install interactively.  However,
>>>> when doing package building, we don't have that luxury.  We could
>>>> mark a port BROKEN if gstreamer-plugins was built without MAD
>>>> support (the default), but that would mean we couldn't package
>>>> it.
>>>
>>> If gstreamer-plugins becomes a metaport selector, no port may
>>> depend on this.  They must depends on a gstreamer-plugins-base and
>>> the plugins it really needs.
>>>
>>> I think it must detect PACKAGE_BUILDING and only depends on
>>> gstreamer-plugins-base in that case.
>>>
>>> This is a real big 'logistic' effort.  It isn't by any means
>>> 'easy'.
>>
>> 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?
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.

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