Date: Wed, 6 Oct 2004 16:20:15 -0400 From: Michael Johnson <ahze@ahze.net> To: Jose M Rodriguez <josemi@freebsd.jazztel.es> Cc: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Re: Gstreamer-plugins splitting ports .. needs testing and feed back ? Message-ID: <226B9192-17D5-11D9-8817-000A958C81C6@ahze.net> In-Reply-To: <200410060925.54385.josemi@freebsd.jazztel.es> References: <F0BECB69-166F-11D9-AC42-000A958C81C6@ahze.net> <200410060817.58787.josemi@freebsd.jazztel.es> <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> <200410060925.54385.josemi@freebsd.jazztel.es>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E9rcoles, 6 de Octubre de 2004 02:51, Joe Marcus Clarke > 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 > 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 =20 > 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/=20 multimedia/gstreamer-plugins-xvid/Makefile?rev=3D1.1.1.1;content-=20 type=3Dtext%2Fplain http://ahze.net:8080/cgi-bin/cvsweb.cgi/~checkout~/gst-ports/=20 multimedia/gstreamer-plugins/Makefile.common?rev=3D1.11;content-=20 type=3Dtext%2Fplain Everything is still in gstreamer-plugins, its setup as master/slave =20 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=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 > > -- > josemi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?226B9192-17D5-11D9-8817-000A958C81C6>