Date: Tue, 5 Oct 2004 14:04:17 +0200 From: Jose M Rodriguez <josemi@freebsd.jazztel.es> To: freebsd-gnome@freebsd.org Cc: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Re: Gstreamer-plugins splitting ports .. needs testing and feed back ? Message-ID: <200410051404.18385.freebsd@redesjm.local> In-Reply-To: <1096942069.45818.5.camel@shumai.marcuscom.com> References: <F0BECB69-166F-11D9-AC42-000A958C81C6@ahze.net> <20041005015106.GG22274@toxic.magnesium.net> <1096942069.45818.5.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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'.
> 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.
>
a gstreamer-plugins-test or gstreamer-plugins-devel port?
> Joe
>
> > # Adam
> >
> >
> > --
> > Adam Weinberger
> > adamw@magnesium.net || adamw@FreeBSD.org
> > adamw@vectors.cx || adamw@gnome.org
> > http://www.vectors.cx
> > _______________________________________________
> > freebsd-gnome@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome
> > To unsubscribe, send any mail to
> > "freebsd-gnome-unsubscribe@freebsd.org"
--
josemi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410051404.18385.freebsd>