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

[Jose M Rodriguez]

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.

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