2009/2/5 Martin Schlander <martin.schlan...@gmail.com>: > 1-click installation as well as manual installation of libxine1 and libxine1- > codecs on openSUSE 11.1 triggers a conflict dialog these days regarding > architecture change from i586 -> i686, or in some cases yast/zypp seems to > just keep the official crippled libxine1 1.1.15 without asking as a "solution" > to the "problem". > > This makes 1-click multimedia installs pretty useless/scary for n00bs and non- > techies, and even manual installation of these crucial packages is a bit > tricky for n00bs. I consider this a serious problem. > > While the solver being too damn sensitive is prolly the core reason for this > particular problem - I wonder if you guys could fix it somehow - for example > by simply dropping i686 versions for the codec stuff. Is there really any good > reason to have those at all? > > Here's the list of conflicts from yast: > > > #### YaST2 conflicts list - generated 2009-02-05 13:35:35 #### > > libxine1-codecs-1.1.16.1-0.pm.1.i686 requires libxine1 = 1.1.16.1, but > this requirement cannot be provided > uninstallable providers: libxine1-1.1.16.1-0.pm.1.i586[Packman Repository] > libxine1-1.1.16.1-0.pm.1.i686[Packman Repository] > [ ] Following actions will be done: > do not install libxine1-1.1.15-20.8.i586 > architecture change of libxine1-1.1.15-20.8.i586 to > libxine1-1.1.16.1-0.pm.1.i686 > install libxine1-1.1.16.1-0.pm.1.i686 (with vendor change) > openSUSE > --> > packman.links2linux.de > architecture change of libxine1-pulse-1.1.15-20.8.i586 to > libxine1-pulse-1.1.16.1-0.pm.1.i686 > install libxine1-pulse-1.1.16.1-0.pm.1.i686 (with vendor change) > openSUSE > --> > packman.links2linux.de > architecture change of libxine1-gnome-vfs-1.1.15-20.8.i586 to > libxine1-gnome-vfs-1.1.16.1-0.pm.1.i686 > install libxine1-gnome-vfs-1.1.16.1-0.pm.1.i686 (with vendor change) > openSUSE > --> > packman.links2linux.de > [ ] do not install libxine1-codecs-1.1.16.1-0.pm.1.i686 > > [ ] Ignore some dependencies of libxine1-codecs > > > > > #### YaST2 conflicts list END ###
Well, YaST would complain anyway if there is a vendor change, wouldn't? Removing the arch change reduces the message length, but not the message itself. Also note that 1-Click isn't so reliable anyway: http://lists.opensuse.org/opensuse-softwaremgmt/2008-12/msg00001.html _______________________________________________ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman