James Cameron wrote: > On Thu, May 07, 2009 at 08:04:27AM +0700, Patrick Shirkey wrote: > >> Obviously. But if one installs ffmpeg from one of the reccomended yum >> repostitories and the version of blender that is installed is not the >> one that is compiled against ffmpeg then it just makes things confusing >> and annoying for an average user. >> > > I disagree, it's just ignorance of the process. While ignorance can > cause annoyance, it's not justified. > > >> But I chose to install blender from a system that is setup to use the >> non restricted packages and instead I get a restricted version. Why is a >> restricted version given priority over a non restricted version? >> > > You should ask the people who prepared the non restricted package > repository. > > Similar situation has happened to me, when a security update was made to > a package in the restricted repository it had a version one higher than > the one in the non-restricted repository. Between the time that the > restricted packager had released a package, and the non-restricted > packager had caught up and released one, any user who updated their > packages would lose functionality. > > It is one of the risks of mixing restricted and unrestricted package > repositories on your system. > > >>>> Jack is included in fedora core IIUC so I have no idea why anyone >>>> would compile mplayer without jack support. >>>> >>> Why not ask them? I imagine you'd find either some bug, or they wanted >>> to promote some other audio interface, or they've made it an optional >>> package. >>> >> There are no major bugs with jack and mplayer has had working jack >> support for over 5 years now. If it's a political decision then that's a >> pretty big call to make. I didn't find any optional packages with yum >> search. >> > > Doesn't have to be a major bug with jack for such a decision to be made > ... a minor bug can do it. And remember that it can be bugs that only > exist between versions of jack and mplayer that you aren't using. > > Again, I think you should ask them. Whinging here about a distribution > packager's choices when the packager isn't going to respond seems a > pointless exercise. > > That's a bit harsh. I'm hardly whinging at all. I'm attempting to have a discussion about a topic that I think has relevance on this list. Basically the seemingly large difference between linux audio apps and their packaging (at least on Fedora) >>>> To me it just highlights the state of multimedia support in Fedora >>>> and possibly other OS's where there is still a level of disconnect >>>> that IMO has been overcome in the LAD community and is shown by the >>>> people who package the audio apps. >>>> >>> On the other hand, it simplifies the packaging, and gets the packages >>> out there in some form that basically works. It might not work to the >>> level of excellence that we demand. A dumbed down distribution. >>> >> Fedora is hardly a dumbed down distribution. IMO it's most likely a >> problem with the people who package for multimedia on Fedora [...] >> > > So talk to them. > > I will once I have assessed the reason behind the decisions and this list is a good place to get an overview as there are several people on it who do have indepth experience with packaging apps. >> but it could be symptomatic of a more institutionalised problem where >> Linux Multimedia is not at the same level that we can see with Linux >> Audio across the board. >> > > Institutionalised? What institution? > > This is a broad reference to Linux Multimedia community if such a thing even exists. We certainly have a Linux Audio community. >> I'm wondering if this could be partly due to the long term affect of >> the annual LAC on the LAD community? >> > > Sorry, I don't know what these acronymns mean. > > LAC: Linux Audio Conference LAD: Linux Audio Developers _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
