Re: Gstreamer (was Re: rhythmbox install...)

I have every gstreamer package installed, no go, I am ready to trash
this idea. Thanks for your input...

On Mon, 2002-11-04 at 17:33, Nick Verhaegen wrote:
> Hmm, 
> 
> 	a small addition, you also need gstreamer-Gconf...
> 
> then it works like in the mail forwarded by matthias. I got it working this 
> way, hope you can too...
> 
> Nick
> 
> On Monday 04 November 2002 23:11, Nick Verhaegen wrote:
> > Hi,
> >
> > 	I had the same problem... Fixed now :) The problem seems to be the
> > dependencies on the rhytmbox rpm. It installs parts of gstreamer rpms, but
> > doesn't install any output plugins...
> >
> > So if you install eg gstreamer-artsd or gstreamer-oss it should work...
> >
> > Output is optional apparently :)
> >
> > Nick Verhaegen
> >
> > On Monday 04 November 2002 21:36, Dale Kosan wrote:
> > > I hope you guys can work this out, I would like to use rhythmbox
> > > someday...Thanks Matthias and Thomas....
> > >
> > > On Mon, 2002-11-04 at 10:49, Thomas Vander Stichele wrote:
> > > > Hey Matthias,
> > > >
> > > > > > I think this is a very good thing for several reasons :
> > > > > > a) user is in control of the dependencies he wants installed
> > > > > >    (ie, we packaged avifile and separated out qt-specific
> > > > > > dependencies, for example)
> > > > >
> > > > > Hmmm, I can't wait for that one to go away and have gstreamer use the
> > > > > great ffmpeg libarary instead! 
> > > >
> > > > Heh, well
> > > > a) avifile will be around for some time
> > > > b) I hope to package up ffmpeg cvs sometime soon
> > > > c) the ffmpeg guys need to do releases
> > > >
> > > > > > b) as seen in red hat 8.0, it means we can provide ogg support
> > > > > > without having to provide mp3 support.  For users who want mp3
> > > > > > support, it is trivial to add it by installing the mp3 rpm.
> > > > >
> > > > > True, but as we are allowed to provide mp3 support with no
> > > > > ambiguities, I don't really see the point of not including it by
> > > > > default. For others to whom it may cause problems, a simple rebuild
> > > > > passing "--without mad" should be enough.
> > > >
> > > > I still disagree.  First of all, I don't want users rebuilding rpms. 
> > > > If they do, that's their problem, but it is hard enough to do support
> > > > for all of the packages we provide already without encouraging users to
> > > > rebuild stuff.  So I totally disagree there - rpms should stay as they
> > > > are.
> > > >
> > > > Second, where do you draw the line ? when do you not add an extra
> > > > format to the rpm ? As I said, GStreamer has support for at least eight
> > > > audio formats, some through more than one package, and so on.  Our
> > > > current idea is fairly simple - one dependency library, one depending
> > > > rpm, and we like it like this.  Specific cases can be changed however,
> > > > but on a per-case basis, and not in a generic way like "put all audio
> > > > formats together".
> > > >
> > > > Third, the day that redhat will package GStreamer is not far off.  I'm
> > > > pretty sure they're not going to package the vorbis and the mp3 plugin
> > > > in the same rpm.
> > > >
> > > > Fourth, it is wrong to claim that people who use mp3 will also use ogg
> > > > and other formats and vice versa.  I have re-encoded every single album
> > > > I own to ogg since the day 1.0 went gold.  All my mp3's are going out
> > > > the door.
> > > >
> > > > From the pov of GStreamer, this division makes sense.  The important
> > > > bit here to stress is that GStreamer itself is a DEVELOPER framework. 
> > > > Any app that uses it should Require: the capabilities it needs and the
> > > > plugins it wants to have.  The problem of making it easier for the user
> > > > to know what plugins to install should be solved by the apps or a
> > > > helper library, NOT by doing some arbitrary stuff in spec files.
> > > >
> > > > This is all just MO of course ;) But I wonder what exactly your
> > > > argument is against splitting up rpms ? The only argument I used to
> > > > have is that it is harder for user to install them.  Apt and Red-Carpet
> > > > obliterated that argument completely.
> > > >
> > > > > Yes, but then users can still get confused by the profusion of
> > > > > sub-packages, and I really don't see the point of separating things
> > > > > that *may* be used one without the other in theory, but won't ever in
> > > > > real life.
> > > >
> > > > They do get used apart from each other, very much.  Also, the confusion
> > > > on the user should be taken care of in the end-user software and the
> > > > package software.  A normal user shouldn't have to run rpm.  My dad
> > > > doesn't.  My dad runs red-carpet.
> > > >
> > > > > > So, at GStreamer we really believe this is the right way to package
> > > > > > GStreamer.  If you throw together all audio formats, you end up
> > > > > > with ten dependency libraries.  If someone only wants vorbis, for
> > > > > > example, then that is too much and you WILL have users complain.
> > > > >
> > > > > Absolutely, but why not put things like Gconf and gnome-vfs in a
> > > > > "gnome" sub-package? (for instance)
> > > >
> > > > Because there are very valid reasons for separating them.  It's not
> > > > because they're both "Gnome technology" that they should be thrown
> > > > together.  gnome-vfs can be really handy in a "handle all sorts of data
> > > > sources" way, without ever having to need GConf.
> > > >
> > > > > I think that what got me to think about that is the confusion made in
> > > > > the naming of the sub-packages, and the naming of the libraries
> > > > > themselves :-/ For example, why "avi" and not "avifile"? Or then why
> > > > > "mad" and not "mp3"? I think there is the real problem... the average
> > > > > user doesn't know that mad is an mp3 decoding library, but I
> > > > > understand that naming the sub-package "mp3" may cause problems if
> > > > > gstreamer decides to support another mp3 deconding library.
> > > >
> > > > This is a valid point, and I have given it some thought myself.  I
> > > > would like to change this somehow to make it more sensible and
> > > > internally consistent, but haven't found a good way to do this (believe
> > > > me, I've tried ;)) But what I *don't* want to do is change it around
> > > > without a good plan.  I spend quite some effort in trying to make
> > > > upgrades work reasonably well, and renaming rpms nilly willy isn't
> > > > going to do me much good ;) So, yes, we need a better naming of
> > > > subpackages, but it has to be thought out.  Feel free to help.
> > > >
> > > > > I also thought about a naming for the packages that would use
> > > > > "output", "input" etc. since for the average user once more, there is
> > > > > no way of knowing easily if the "quicktime" package allows decoding,
> > > > > encoding or both. Maybe putting something similar and easily
> > > > > identifiable for this in the summary for each and every sub-package
> > > > > would be enough?
> > > >
> > > > Yeah, descriptions might be better.  I don't think it should be handled
> > > > in the name though.  Personally, I feel we should name the package
> > > > based on the name of the lib.  I'm going to have to discuss this again
> > > > with the others.
> > > >
> > > > > > The details on how to cooperate the most efficiently I think we
> > > > > > should hammer out over irc ;)
> > > > >
> > > > > Hell, no! I've stopped IRC about 3 years ago, and it's incredible how
> > > > > my productivity has gone up since ))))
> > > >
> > > > Heh - well I feel we're going to lose a lot of mail time over this if
> > > > not ;)
> > > >
> > > > > I fully understand you, and just hope to help you out a bit with
> > > > > ideas and package changes 
> > > > > I can't ignore gstreamer anymore myself, since getcontrol relies on
> > > > > it
> > > > >
> > > > > )
> > > >
> > > > Hahaha ;) then you're screwed ;) We converted Julien, and you're next.
> > > > We're taking over your desktop one by one ;)
> > > >
> > > > Seriously, I want to work this out.  But you will have a hard time
> > > > convincing me of grouping packages more, and I think it's not necessary
> > > > either since that is not the core of our discussion anyway ;) I'm happy
> > > > to discuss these sorts of things with you in the future, but let's
> > > > concentrate on the other problems first, because this is a long-time
> > > > cooperation ;)
> > > >
> > > > hope to hear,
> > > > Thomas
> > > >
> > > >  --
> > > >
> > > > The Dave/Dina Project : future TV today ! -
> > > > http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org
> > > > -*-> The girl that I could never hurt
> > > > had to go and lose all that power over me
> > > > and I claimed victory
> > > > <-*- thomas  (at) apestaart (dot) org -*->
> > > > URGent, the best radio on the Internet - 24/7 ! -
> > > > http://urgent.rug.ac.be/
> > > >
> > > >
> > > > _______________________________________________
> > > > RPM-List mailing list <RPM-List <at> freshrpms.net>
> > > > http://lists.freshrpms.net/mailman/listinfo/rpm-list
> >
> > _______________________________________________
> > RPM-List mailing list <RPM-List <at> freshrpms.net>
> > http://lists.freshrpms.net/mailman/listinfo/rpm-list
> 
> 
> _______________________________________________
> RPM-List mailing list <RPM-List <at> freshrpms.net>
> http://lists.freshrpms.net/mailman/listinfo/rpm-list
-- 
http://www.winsweptrottweilers.com

ICQ# 55846749

Registered Linux user #191829

A Cherokee Prayer:

Oh Great Spirit,

Help me always to speak the truth quietly,

to listen with an open mind when others speak

and to remember the peace that may be found in 

silence.

_______________________________________________
RPM-List mailing list <RPM-List <at> freshrpms.net>
http://lists.freshrpms.net/mailman/listinfo/rpm-list