I don’t know if it’s a problem with Yast or the packages themselves, but it’s been my experience that for some Packman packages, the dependencies seem to be seriously messed up.
In the case of the Totem plugin, one of the packages Yast wanted to pull in was Brasero, which made absolutely no sense to me. What does cd/dvd burning have to do with watching videos in a browser? So I decided to try installing the supposedly-required packages one by one, and as luck would have it, just installing the first one on the list enabled me to subsequently install the Totem plugin without Yast wanting to install any of the other packages it had previously insisted were needed. The plugin has been working fine without them. (Unfortunately, it was a few months ago, and I didn’t note which package it was, or I’d tell you.)
Even worse was my experience trying to install the gstreamer-0_10-plugins-bad-32bit and gstreamer-0_10-plugins-ugly-32bit packages, which I needed for 32 bit Wine. Yast wanted to change the architecture of over 400 other packages on my system when I selected the Packman packages. Instead, I got the packages from the Multimedia repository, which installed without Yast wanting to change the architecture of anything, and they work fine.
I’ve used Packman for years, but lately, I don’t trust it so much.
@dimesio
It can be troublesome I know.
But it’s more a matter of understanding the way thru the somewhat complicated dependency mess.
I agree, it shouldn’t be so tricky.
And I don’t really have a proper answer. Though I could probably walk users thru a solution. But it sounds like you managed OK on your own.
There is a Brasero plugin. totem-plugins recommends brasero because of that, but it’s not a requirement and you can just tell to YaST “thanks, but no, thanks”.
Then perhaps part of the problem is that YaST isn’t clear enough about what’s required and what’s merely recommended. But that still doesn’t explain why YaST stopped “recommending” Brasero (and a bunch of other packages) after I installed the one at the top of the list. Nor does it explain YaST wanting to change the architecture of several hundred packages to i586 when I tried to install the x86_64 packages of the 32 bit “bad” and “ugly” gstreamer plugins from Packman.
I never use it, zypper is totally clear here. From a quick look it seems the only way to see is right-clicking and selecting “Show solver information”. So I agree, the problem is that YaST isn’t clear enough about this. Why no YaST user opened a bug/enhancemente report about this is the only thing I fail to understand.
I would need more info to know. The output of Extras->“Generate Dependency Respolver Test Case” would make it clear.
No need to install the ugly, it’s enough with the bad. The cause is that:
a) ZYpp doesn’t allow to install the i586 and x86_64 versions of a package at the same time. I don’t really agree with this, it is an artificial limitation, but openSUSE has a different method.
b) The openSUSE specific method isn’t used in the mjpegtools package. So to install gstreamer-0_10-plugins-bad-32bit you need to change the architecture of mjpegtools-libs. Then a chain of dependencies in low level libraries triggers the change in everything else.
So this last problem is still happening today… probably because you didn’t report it? I will fix it now…
Possibly because those of us who never use zypper would have no way of knowing that there was anything to report in the first place.
I would need more info to know. The output of Extras->“Generate Dependency Respolver Test Case” would make it clear.
The output was a 24.3 MB tgz file, so I’ll take that as rhetorical. But you’ve given me something to study over winter break.
So this last problem is still happening today… probably because you didn’t report it?
Point taken. The short but brutal reason is that I was very busy at the time this came up and my immediate problem was solved by using the packages from Multimedia.
I will fix it now…
I didn’t know you were the person to contact. I’ll keep that in mind.