[packman] libxine1/libxine1-codecs problems with conflict dialogs
Martin Schlander
martin.schlander at gmail.com
Thu Feb 5 15:02:56 CET 2009
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 ###
More information about the Packman
mailing list