On Monday 07 July 2003 23:51, G�tz Waschk wrote: > Am Montag, 7. Juli 2003, 18:05:42 Uhr MET, schrieb Andi Payn: > > 2. xine-lib-compat-plugins-0.9.13-11mdk vs. xine-plugins-1-0.beta12.5mdk > > These both provide and obsolete xine-xv, xine-gl, and xine-oss. The > > result is that, if you have both installed, upgrading to a new > > version of xine-plugins via rpm fails, while upgrading it via urpmi > > removes xine-lib-compat-plugins and all codecs that haven't been > > ported to 1.0 yet (which includes divx4). > > > > Solution: xine-lib-compat-plugins should neither provide nor > > obsolete xine-xv, xine-gl, and xine-oss (any package that requires > > those should be pulling in the current xine-plugins, right?). > > No, that's not the solution. The right thing would be to remove > xine-lib-compat, as it's obsolete. I tried that but I don't have the > right permissions for the rpmctl command on main.
This is exactly what I wanted someone besides me (ideally the package maintainers) to look at each one of the problems: I was pretty sure I'd be wrong about some of them (and a few, as I mentioned, I had no idea what needed to be done). However, some of the plugins still require xine-lib-compat-plugins. I haven't checked, so maybe all of the affected plugins are PLF-only, but they include pretty important things (like the divx4 codec). Maybe these all just need to be recompiled against xine-plugins, but it would be good to know that (and know that it was going to be done) before getting rid of the compat libs. Also, kxine and sinek require the compat libs. Since neither of these is in Cooker, maybe someone's decided they're no longer useful enough to update. If that's true, for people upgrading from 9.1 to Cooker (or 9.2), would it be useful to have xine-plugins explictly Conflict them (<= their last version)?
