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

[Jose M Rodriguez]

El Miércoles, 6 de Octubre de 2004 02:51, Joe Marcus Clarke escribió:
> 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 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.

> > > 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 
port and add the knobs in other port.  This will make actual ports 
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 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

--
  josemi