Date: Wed, 6 Oct 2004 08:17:58 +0200 From: Jose M Rodriguez <josemi@freebsd.jazztel.es> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: freebsd-gnome@freebsd.org Subject: Re: Gstreamer-plugins splitting ports .. needs testing and feed back ? Message-ID: <200410060817.58787.josemi@freebsd.jazztel.es> In-Reply-To: <1097023904.79913.24.camel@shumai.marcuscom.com> References: <F0BECB69-166F-11D9-AC42-000A958C81C6@ahze.net> <200410051404.18385.freebsd@redesjm.local> <1097023904.79913.24.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.=20
> 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=20
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=20
installed.
I also think that a port selector isn't needed.
At last here, the safest and easy path seems:
=2D Convert multimedia/gstreamer-plugin in a base plugin port with fixed=20
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.
=2D Add external ports to the rest.
> > > 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.
>
Allright. But seems easy convert gstreamer-plugins in a fixed content=20
port and add the knobs in other port. This will make actual ports=20
depenencies on gstreamer-plugins still valid after change.
> Of course, if the maintainer(s) are willing to forgo this, and handle
> all the upgrade work themselves, who am I to complain.
>
> Joe
>
sure.
> > > 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
=2D-
josemi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410060817.58787.josemi>