From owner-freebsd-gnome@FreeBSD.ORG Wed Oct 6 20:20:24 2004 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECA5816A4CF for ; Wed, 6 Oct 2004 20:20:24 +0000 (GMT) Received: from imf24aec.mail.bellsouth.net (imf24aec.mail.bellsouth.net [205.152.59.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E9E443D45 for ; Wed, 6 Oct 2004 20:20:24 +0000 (GMT) (envelope-from ahze@ahze.net) Received: from [192.168.1.5] ([68.209.163.3]) by imf24aec.mail.bellsouth.netESMTP <20041006202018.LKYL1757.imf24aec.mail.bellsouth.net@[192.168.1.5]>; Wed, 6 Oct 2004 16:20:18 -0400 In-Reply-To: <200410060925.54385.josemi@freebsd.jazztel.es> References: <200410060817.58787.josemi@freebsd.jazztel.es> <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> <200410060925.54385.josemi@freebsd.jazztel.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <226B9192-17D5-11D9-8817-000A958C81C6@ahze.net> Content-Transfer-Encoding: quoted-printable From: Michael Johnson Date: Wed, 6 Oct 2004 16:20:15 -0400 To: Jose M Rodriguez X-Mailer: Apple Mail (2.619) cc: FreeBSD GNOME Users Subject: Re: Gstreamer-plugins splitting ports .. needs testing and feed back ? X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 20:20:25 -0000 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