This is just the result of the totem-xine review request. Changes: * Goes through the build twice so that both backends can be built * Uses --program-suffix "-$BACKEND" to handle the binary files from the different backends (Backends are placed in subpackages) * Uses gconf to determine the backend to use at runtime I've attached the working spec file and patches, I'll upload an SRPM tomorrow.
Created attachment 223871 [details] New totem spec file
Created attachment 223881 [details] Patch to add the new gconf option
Created attachment 223891 [details] Script to retrieve and run the correct backend based on gconf values
Oh, the final recompile finished sooner than I thought. Here's the SRPM: http://www.diffingo.com/downloads/diffingo-repo/review/totem-2.20.0-3.fc8.src.rpm
Little problem. The nautilus extension is another program that depends on a specific backend: %{_libdir}/nautilus/extensions-1.0/*.so* There should only be one in there, at any one time. This is probably a good use of alternatives. Could you please add a "--set [backend name]" to the shell script that would set the alternatives properly (if root), and modify the gconf value in all cases? The Mozilla plugin doesn't seem to be switchable either: %{_libexecdir}/totem-plugin-viewer-gstreamer %{_libexecdir}/totem-plugin-viewer-xine You can leave the backends in the main backend packages, and have the actual mozilla plugins in that package.
Comment on attachment 223881 [details] Patch to add the new gconf option Please follow the existing code style and identation in the patch.
In the .spec: Requires: %{name}-gstreamer = %{version}-%{release} Requires: %{name}-xine = %{version}-%{release} Add virtual Provides: in the backends, and add a Requires: totem-backend in the main package, so people can choose to install only one backend. Finally, please mark your text attachments as "text/plain", and attach your .spec file changes as patches (generated with "cvs diff -up", the CVS can be checked out as an anonymous user).
Where do you suggest I store actual .so's for the nautilus plugin? (I'm assuming that nautilus will load and .so in that directory so we can't have both .so original folder)
Created attachment 226231 [details] totem.spec patch Here is the new spec file
Created attachment 226241 [details] Script used to start backend-specific binaries
Created attachment 226251 [details] Schema patch to support "backend" key/value pair
Created attachment 226281 [details] Script used to start backend-specific binaries Fixed a glitch with the totem script when using it to open files in Nautilus
Created attachment 233441 [details] Script used to start backend-specific binaries Fixed another bug where indexing videos would make the script switch to gstreamer. (-s is a valid switch for totem-video-thumbnailer. The wrapper script now uses -b to switch backends)
Just noticed there's missing quotes in attachment 233441 [details] around the $*, second to last line.
Created attachment 247201 [details] totem.spec patch for 2.21.1 Updated for 2.21.1
Created attachment 247211 [details] Script used to start backend-specific binaries New script which uses $@ rather than $* to workaround a bug, as well as includes quotes to function properly with files including spaces.
Any updates on the upstream effort?
Created attachment 296650 [details] New patch for 2.21.95
Created attachment 296651 [details] Don't build help files
Created attachment 296652 [details] Fixes some translation problems, patches 2.21.95 to svn head as of 20080303
Created attachment 296663 [details] Script used to start backend-specific binaries Now passes arguments onto totem-$backend binary
Committed with 2.21.96-1
Good work, but those nautilus plugins really should go in a subdir of %{_libdir}not in libdir itself, libdir itself is only for libraries.
It was completely broken, package upgrade-wise, so I went a different way. Totem now installs the backend as a shared library, instead of having it statically linked in all the binaries. There's a totem-backend shell script to launch totem and other binaries with a specific backend. Eg: totem-backend -b xine totem dvd:// If run as root, it will switch the backend for the whole system, eg.: totem-backend -b xine although, that's not implemented right now... Anybody willing to write the crazy update-alternatives line?
Sure - So it's the same as what the script did before but I'm using alternatives to switch the symlinks?
Implementation is completely different though... The only symlink you can switch is whether: $(libdir)/libbaconvideowidget.so.0.0.0 points to $(libdir)/libbaconvideowidget-gstreamer.so.0.0.0 or $(libdir)/libbaconvideowidget-xine.so.0.0.0
Reopening, alternatives code attached
Created attachment 296927 [details] The scriptlets and code needed to switch backends
Created attachment 297066 [details] This patch adds the required 'alternatives' commands
Created attachment 297070 [details] Adds the required 'alternatives' commands Fixed a stupid typo...
Created attachment 297102 [details] Adds the required 'alternatives' commands Removed a few lines from %files and calls ldconfig in the main package's post scriptlet (until we call ldconfig after installation, libbaconvideowidget.so.0 always point to xine). Tested this a few times, works after every installation and the script switches as it should.
Could you split that on multiple lines, and say something like "the xine backend is not available": + echo -e 'Error: One or both of the libbaconvideowidget files not found!\nPlease check your totem installation.' I don't understand that: +# works around %{_libdir}/libbaconvideowidget.so.0.0.0 pointing to xine (and +# therefore alternatives setup is ignored) +/sbin/ldconfig Otherwise looks good to commit.
I'm xine is build after gstreamer, so %{_libdir}/libbaconvideowidget.so.0.0.0 ends up pointing to the xine backend: at that point in time, the alternatives don't exist so the xine library is selected by ld[config]. Once a backend has been installed and the wrapper symlink (the one we use with alternatives) is in place, ldconfig uses that instead. So after all backends install, we need to call a final ldconfig. I just checked and realized the true problem - ldconfig is called before the alternatives command in the %post and %postun scriptlets... Fixing+testing now, if it works I'll attach a new patch.
Created attachment 298004 [details] Adds the required 'alternatives' commands (revised) Yup, that did it. Patches backend script and spec at once, obsoleting those patches
Looks good, please commit and kick a build.
Release notes: ---8<--- Totem, the default movie player, now has the ability to switch playback backends without recompilation, or replacing the default package. To change the backend system-wide: yum install totem-xine totem-backend -b xine To run totem with the xine-lib backend: yum install totem-xine totem-backend -b xine totem ---8<--- I'm sure somebody can come up with a slightly better wording...
How does this sound? Release notes: ---8<--- Totem, the default movie player for Gnome, now has the ability to switch playback backends without recompilation or switching packages! To install the xine backend, run: yum install totem-xine To run totem with the xine backend once, execute: totem-backend -b xine totem If you'd like to change the default backend to xine for the entire system, execute as root: totem-backend -b xine Once using the xine backend, you can temporarily use the gstreamer backend in the same manner: totem-backend -b gstreamer totem Or to change the default backend back to gstreamer: totem-backend -b gstreamer ---8<---
Without the exclamation mark, and once you've actually committed your patch :)
Done - I also changed Source0 from 2.21 to 2.23 which wasn't in the patch original because "spectool -g" was returning 404...
Created attachment 298705 [details] totem.spec "Requires" patch I think it is better to require %{name}-backend, not %{name}-gstreamer. In this case we can remove totem-gstreamer and leave only totem-xine.
(In reply to comment #40) > Created an attachment (id=298705) [edit] > totem.spec "Requires" patch > > I think it is better to require %{name}-backend, not %{name}-gstreamer. In this > case we can remove totem-gstreamer and leave only totem-xine. Not a typo. Otherwise doing a "yum install totem" will install "totem-xine" instead of "totem-gstreamer" as its name is shorter. I blame yum...
Adding FutureFeature keyword to RFE's.
(In reply to comment #42) > Adding FutureFeature keyword to RFE's. Did you even read the bug? It's already implemented.
Totem in rawhide defaults to xine instead of gstreamer. We need to fix that if we want to codeina to work.
(In reply to comment #44) > Totem in rawhide defaults to xine instead of gstreamer. We need to fix that if > we want to codeina to work. No it doesn't. Read the scripts in the totem.spec, the GStreamer backend has a higher priority than the xine-lib one. Must be a side-effect of upgrading from an old version.