Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Oct 2004 16:20:15 -0400
From:      Michael Johnson <ahze@ahze.net>
To:        Jose M Rodriguez <josemi@freebsd.jazztel.es>
Cc:        FreeBSD GNOME Users <gnome@freebsd.org>
Subject:   Re: Gstreamer-plugins splitting ports .. needs testing and feed back ?
Message-ID:  <226B9192-17D5-11D9-8817-000A958C81C6@ahze.net>
In-Reply-To: <200410060925.54385.josemi@freebsd.jazztel.es>
References:  <F0BECB69-166F-11D9-AC42-000A958C81C6@ahze.net> <200410060817.58787.josemi@freebsd.jazztel.es> <04B570E1-1763-11D9-8817-000A958C81C6@ahze.net> <200410060925.54385.josemi@freebsd.jazztel.es>

next in thread | previous in thread | raw e-mail | index | archive | help

On Oct 6, 2004, at 3:25 AM, Jose M Rodriguez wrote:

> On Wednesday 06 October 2004 08:43, Michael Johnson wrote:
>> On Oct 6, 2004, at 2:17 AM, Jose M Rodriguez wrote:
>>> El Mi=E9rcoles, 6 de Octubre de 2004 02:51, Joe Marcus Clarke
> escribi=F3:
> [...]
>>>> 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.
>>
>> What should the "most basic install" be? which plugins should it  be
>> built with?
>
> A really good question for the port maintainer.
>
> This is more a 'logistic' problem.  If gstreamer have 50 diff plugins
> and you want implement all in a per-port basic, you may have 51 ports
> to maintain, carry on dependencies ...
>
> This is really a big effort that must be take by the port maintainer.
>
> If you can name 20 that allway be in, you have 31 ports.  You can =20
> refine
> this in future works.  And you have more chances that this can be
> assumed by the port maintainer.
>


Actually it won't be much different than it is now, just more ports
Please take a look at
Makefile from xvid
and Makefile.common from gstreamer-plugins
http://ahze.net:8080/cgi-bin/cvsweb.cgi/~checkout~/gst-ports/=20
multimedia/gstreamer-plugins-xvid/Makefile?rev=3D1.1.1.1;content-=20
type=3Dtext%2Fplain
http://ahze.net:8080/cgi-bin/cvsweb.cgi/~checkout~/gst-ports/=20
multimedia/gstreamer-plugins/Makefile.common?rev=3D1.11;content-=20
type=3Dtext%2Fplain

Everything is still in gstreamer-plugins, its setup as master/slave =20
ports so you basically only edit one file.

Michael

> So, about the big question, you have really two.
>
> - What must be take-off
> things like arts and some special supports.  Even seems that kde@ must
> be responsible off dependencies on gstreamer-plugins-arts from
> kdemultimedia (as an example).
>
> - What must be in
> first, things that must be problematic out of the base port.
> second, what allways be there.  Take a package from bento, expand the
> tarball and examine the plugins.
>
> If you allready have work done to make ports for every plugin, make =
the
> gstreamer-plugins port depends on these.  But it must be a fixed
> content port and you must have just only one keyword to select it.
>
>> 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.
>>
>
> You may rework this after the gstreamer-plugins redef.  The ports must
> depend on gstreamer-plugins and the gstreamer-plugins-{extra} they
> really need.  You may make this via keywords if you like.
>
>> Here's what I have so far..
>> gnomemedia2/Makefile:USE_GSTREAMER=3D     cdparanoia
>> 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
>>
>> 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
>
> --
>   josemi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?226B9192-17D5-11D9-8817-000A958C81C6>