Date: Wed, 6 Oct 2004 09:25:53 +0200 From: Jose M Rodriguez <josemi@freebsd.jazztel.es> To: Michael Johnson <ahze@ahze.net> Cc: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Re: Gstreamer-plugins splitting ports .. needs testing and feed back ? Message-ID: <200410060925.54385.josemi@freebsd.jazztel.es> In-Reply-To: <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> References: <F0BECB69-166F-11D9-AC42-000A958C81C6@ahze.net> <200410060817.58787.josemi@freebsd.jazztel.es> <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 06 October 2004 08:43, Michael Johnson wrote:
> On Oct 6, 2004, at 2:17 AM, Jose M Rodriguez wrote:
> > El Mi=E9rcoles, 6 de Octubre de 2004 02:51, Joe Marcus Clarke=20
escribi=F3:
[...]
> >> 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=20
and you want implement all in a per-port basic, you may have 51 ports=20
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=20
this in future works. And you have more chances that this can be=20
assumed by the port maintainer.
So, about the big question, you have really two.
=2D What must be take-off
things like arts and some special supports. Even seems that kde@ must=20
be responsible off dependencies on gstreamer-plugins-arts from=20
kdemultimedia (as an example).
=2D 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=20
tarball and examine the plugins.
If you allready have work done to make ports for every plugin, make the=20
gstreamer-plugins port depends on these. But it must be a fixed=20
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=20
depend on gstreamer-plugins and the gstreamer-plugins-{extra} they=20
really need. You may make this via keywords if you like.
> Here's what I have so far..
> gnomemedia2/Makefile:USE_GSTREAMER=3D cdparanoia
> jamboree/Makefile:USE_GSTREAMER+=3D esound
> jamboree/Makefile:USE_GSTREAMER+=3D mad vorbis
> marlin/Makefile:USE_GSTREAMER=3D cdparanoia
> rhythmbox/Makefile:GST_PLUGINS=3D musicbrainz gnomevfs flac mad
> rhythmbox/Makefile:USE_GSTREAMER+=3D faad
> rhythmbox/Makefile:USE_GSTREAMER+=3D ${GST_PLUGINS}
> rhythmbox/Makefile:USE_GSTREAMER+=3D ${GST_PLUGINS}
> rhythmbox/Makefile:USE_GSTREAMER+=3D vorbis
> sound-juicer/Makefile:USE_GSTREAMER=3D cdparanoia vorbis flac lame
> tunesbrowser/Makefile:USE_GSTREAMER=3D mad
> tunesbrowser/Makefile:USE_GSTREAMER+=3D esound
> nautilus-media/Makefile:USE_GSTREAMER=3D 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
=2D-
josemi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410060925.54385.josemi>