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

[Joe Marcus Clarke]

On Wed, 2004-10-06 at 02: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ó:
> >> 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 think it should be whatever the default set is if you had no external
codecs/applications installed.  Ports can then choose to depend on
exactly what they need.

> 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

Not needed for now.  gnomemedia2 just depends on the gstreamer OSS stuff
currently.

> 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

Actually, the for I think about it, this guy should depend on Hermes as
well.

Joe

> 
> 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
> 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20041006/c94250a1/attachment-0001.bin