From owner-freebsd-gnome@FreeBSD.ORG Wed Oct 6 06:43:25 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 5653F16A4CE; Wed, 6 Oct 2004 06:43:25 +0000 (GMT) Received: from imf20aec.mail.bellsouth.net (imf20aec.mail.bellsouth.net [205.152.59.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0AF343D54; Wed, 6 Oct 2004 06:43:24 +0000 (GMT) (envelope-from ahze@ahze.net) Received: from [192.168.1.5] ([68.209.163.3]) by imf20aec.mail.bellsouth.netESMTP <20041006064324.MBKV1719.imf20aec.mail.bellsouth.net@[192.168.1.5]>; Wed, 6 Oct 2004 02:43:24 -0400 In-Reply-To: <200410060817.58787.josemi@freebsd.jazztel.es> References: <200410051404.18385.freebsd@redesjm.local> <1097023904.79913.24.camel@shumai.marcuscom.com> <200410060817.58787.josemi@freebsd.jazztel.es> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> Content-Transfer-Encoding: quoted-printable From: Michael Johnson Date: Wed, 6 Oct 2004 02:43:23 -0400 To: Jose M Rodriguez X-Mailer: Apple Mail (2.619) cc: FreeBSD GNOME Users cc: freebsd-gnome@freebsd.org 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 06:43:25 -0000 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: >> 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=20= > 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=20 built with? 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=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