From owner-freebsd-gnome@FreeBSD.ORG Wed Oct 6 15:34:53 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 D9A5616A4CE; Wed, 6 Oct 2004 15:34:53 +0000 (GMT) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D15843D3F; Wed, 6 Oct 2004 15:34:53 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i96FYcpl015856; Wed, 6 Oct 2004 11:34:38 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Michael Johnson In-Reply-To: <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> References: <200410051404.18385.freebsd@redesjm.local> <1097023904.79913.24.camel@shumai.marcuscom.com> <200410060817.58787.josemi@freebsd.jazztel.es> <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-m3czEEq3DOaOx6k9jLfY" Organization: MarcusCom, Inc. Message-Id: <1097076883.95993.12.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 11:34:43 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com 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 15:34:54 -0000 --=-m3czEEq3DOaOx6k9jLfY Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 2004-10-06 at 02:43, Michael Johnson wrote: > On Oct 6, 2004, at 2:17 AM, Jose M Rodriguez wrote: >=20 > > 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. >=20 > What should the "most basic install" be? which plugins should it be=20 > built with? I think it should be whatever the default set is if you had no external codecs/applications installed. Ports can then choose to depend on exactly what they need. > 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. >=20 > Here's what I have so far.. > gnomemedia2/Makefile:USE_GSTREAMER=3D cdparanoia Not needed for now. gnomemedia2 just depends on the gstreamer OSS stuff currently. > 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 Actually, the for I think about it, this guy should depend on Hermes as well. Joe >=20 > 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 >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-m3czEEq3DOaOx6k9jLfY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBZBCTb2iPiv4Uz4cRAnmGAKCVFJORLIkNZZts0I3PxrTfrEPZJACcCans UkwX9fao/tcR6k8wCGC3a7M= =jk0J -----END PGP SIGNATURE----- --=-m3czEEq3DOaOx6k9jLfY--