Gstreamer-plugins splitting ports .. needs testing and feed back ?

[Joe Marcus Clarke]

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?).

> 
> > 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?

Ideally, we shouldn't need an additional port.  The gstreamer-plugins
port should have the knobs to do this.  However, if it would be easier,
then creating a separate test port would be okay.

Of course, if the maintainer(s) are willing to forgo this, and handle
all the upgrade work themselves, who am I to complain.

Joe

> 
> > Joe
> >
> > > # Adam
> > >
> > >
> > > --
> > > Adam Weinberger
> > > adamw at magnesium.net || adamw at FreeBSD.org
> > > adamw at vectors.cx    ||   adamw at gnome.org
> > > http://www.vectors.cx
> > > _______________________________________________
> > > freebsd-gnome at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome
> > > To unsubscribe, send any mail to
> > > "freebsd-gnome-unsubscribe at freebsd.org"
> 
> --
>   josemi
-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20041005/e899572e/attachment-0001.bin