From owner-freebsd-gnome@FreeBSD.ORG Wed Oct 6 07:37:15 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 CFDB716A4CE for ; Wed, 6 Oct 2004 07:37:15 +0000 (GMT) Received: from smtp2.jazztel.es (smtp2.jazztel.es [62.14.3.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05A9C43D3F for ; Wed, 6 Oct 2004 07:37:15 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from antivirus by smtp2.jazztel.es with antivirus id 1CF6MD-0002C4-00 Wed, 06 Oct 2004 09:37:05 +0200 Received: from [212.106.254.137] (helo=rguez.homeunix.net) by smtp2.jazztel.es with esmtp id 1CF6MC-0002BQ-00 Wed, 06 Oct 2004 09:37:04 +0200 Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by rguez.homeunix.net (8.13.1/8.13.1) with ESMTP id i967Q2wK001032; Wed, 6 Oct 2004 09:26:02 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.1/8.13.1/Submit) id i967PsRk002092; Wed, 6 Oct 2004 09:25:54 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) X-Authentication-Warning: orion.redesjm.local: freebsd set sender to josemi@freebsd.jazztel.es using -f From: Jose M Rodriguez To: Michael Johnson Date: Wed, 6 Oct 2004 09:25:53 +0200 User-Agent: KMail/1.7 References: <200410060817.58787.josemi@freebsd.jazztel.es> <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> In-Reply-To: <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410060925.54385.josemi@freebsd.jazztel.es> X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.27.0.12; VDF 6.27.0.81 (host: antares.redesjm.local) X-Virus-Scanned: by antivirus 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 07:37:15 -0000 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