[Bug 310455] New: Installing Amarok (from Packman) issues
https://bugzilla.novell.com/show_bug.cgi?id=310455 Summary: Installing Amarok (from Packman) issues Product: openSUSE 10.3 Version: Beta 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: kkaempf@novell.com ReportedBy: francisg@gmail.com QAContact: kkaempf@novell.com Found By: --- Created an attachment (id=164004) --> (https://bugzilla.novell.com/attachment.cgi?id=164004) y2logs Installing Amarok from Packman completely fails with the message: #### YaST2 conflicts list - generated 2007-09-13 22:01:07 #### amarok-xine cannot be installed due to missing dependencies There are no installable providers of amarok == 1.4.7-111.pm.4 for amarok-xine-1.4.7-111.pm.4.i586[Packman] === amarok-xine-1.4.7-111.pm.4.i586[Packman] === amarok-xine-1.4.7-111.pm.4.i586[Packman] will be installed by another application. (ApplLow/ApplHigh) amarok-1.4.7-26.i586 is needed by amarok-xine-1.4.7-111.pm.4.i586[Packman] (libamarok.so.0) amarok-1.4.7-111.pm.4.i586[Packman] provides amarok == 1.4.7-111.pm.4, but has another architecture. amarok-xine-1.4.7-111.pm.4.i586[Packman] is needed by amarok-1.4.7-26.i586 (amarok_engine) (null) Conflict Resolution: ( ) Install amarok although it would change the architecture ( ) do not install amarok-xine ( ) Ignore this requirement just here No valid solution found with just resolvables of best architecture. With this run only resolvables with the best architecture have been regarded. Regarding all possible resolvables takes time, but can come to a valid result. Conflict Resolution: ( ) Make a solver run with ALL possibilities. #### YaST2 conflicts list END ### ..I've been told that this isn't a packaging issue, and that it works fine with Smart. If you tinker with other things you get a lot of libtunepimp errors. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=310455#c1
Benjamin Weber
https://bugzilla.novell.com/show_bug.cgi?id=310455#c2
Klaus Kämpf
https://bugzilla.novell.com/show_bug.cgi?id=310455
Klaus Kämpf
https://bugzilla.novell.com/show_bug.cgi?id=310455#c3
Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c4
Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c5
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=310455#c6
--- Comment #6 from Stefan Schubert
https://bugzilla.novell.com/show_bug.cgi?id=310455#c7
--- Comment #7 from Stefan Schubert
https://bugzilla.novell.com/show_bug.cgi?id=310455#c8
Stefan Schubert
!> amarok-xine cannot be installed due to missing dependencies !> There are no installable providers of amarok == 1.4.7-111.pm.4 for amarok-xine-1.4.7-111.pm.4.i586[1] !> Solution: !> Install amarok although it would change the vendor !> amarok-1.4.7-111.pm.4.i586[1] provides this dependency, but would change the vendor of the installed item !> Solution: !> do not install amarok-xine !> do not install amarok-xine-1.4.7-111.pm.4.i586[1] !> Solution: !> Ignore this requirement just here
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=310455#c9
--- Comment #9 from Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c10
--- Comment #10 from Benjamin Weber
https://bugzilla.novell.com/show_bug.cgi?id=310455#c11
--- Comment #11 from Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c12
Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c13
Stefan Schubert
https://bugzilla.novell.com/show_bug.cgi?id=310455#c14
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=310455#c15
Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c16
--- Comment #16 from Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c17
Pascal Bleser
https://bugzilla.novell.com/show_bug.cgi?id=310455#c18
Alberto Passalacqua
https://bugzilla.novell.com/show_bug.cgi?id=310455#c19
Detlef Reichelt
https://bugzilla.novell.com/show_bug.cgi?id=310455#c20
--- Comment #20 from Pascal Bleser
https://bugzilla.novell.com/show_bug.cgi?id=310455#c21
--- Comment #21 from Benjamin Weber
https://bugzilla.novell.com/show_bug.cgi?id=310455#c22
--- Comment #22 from Pascal Bleser
Patch doesn't do what it's intended to do. I've no idea why but libzypp thinks the architecture is changing when the vendor comparison returns true.
This is really, really weird, and definitely smells like a bug somewhere else. If that's the case, then considering "SUSE" and "openSUSE" as equal vendors doesn't work either (that's 2 lines higher than my patch in that C++ file).
Also just disabling the vendor sticky doesn't solve the problem, although it is arguably the lesser of two evils at this point.
Absolutely, I forgot to add that. The best solution would be to have an informative message in the actions to be performed (that a vendor change will take place for that package), but not to prompt the user about whether to do the vendor change. And indeed, in my opinion too, it's better to not have any vendor change handling at all than the current situation. Unless there's time to implement the suggestion above (have an informative message instead of doing it silently) ;) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=310455#c23
--- Comment #23 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=310455#c24
--- Comment #24 from Francis Giannaros
https://bugzilla.novell.com/show_bug.cgi?id=310455#c25
--- Comment #25 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=310455#c26
Hendrik Vogelsang
https://bugzilla.novell.com/show_bug.cgi?id=310455
Hendrik Vogelsang
https://bugzilla.novell.com/show_bug.cgi?id=310455#c27
--- Comment #27 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=310455#c28
--- Comment #28 from Pascal Bleser
It's worth to note though that only installing packages that replace packages is a problem. Installing from 3rd party repo is not a problem in general.
True.
So my suggestion to packman would be to provide amarok-xine-pm, because then you can register packman and can pick only those packages you want to have from them. Right now it would simply battle with KDE:Backports who first gets the latest version out. But if there is an amarok-xine-pm it's clear the user wants to wait for the version update in packman repo.
Yes. Or rather, the user explicitly wants to have the amarok build with support for MP4 (as MP3 and such is actually handled by Packman's libxine1), MySQL and PostgreSQL (which are the other features not present in the SUSE amarok builds). That's an option. What we were discussing and considering yesterday was to create an additional subpackage "amarok-with-full-codec-support" that would explicitly Requires: the Packman amarok packages. That would at least prevent from accidental upgrades to the KDE:Backports amarok packages (and loosing full codec support). But it won't work around this bug in the solver (it's definitely a bug to me).
And this seems to be very general problem _within the packman project_. Our policy change just made it clearer where the problem is.
How is providing upgrades of packages present in SUSE a "general problem within the packman project" ?
I'm aware that some people in the CC feel that every packman package is better than any other package out there and it's very fine to be proud of it (I completely agree with Henne there), but I still feel that it should be left to the user to decide what he wants from whom.
Sure. And the question isn't that the Packman packages are better than SUSE packages -- which isn't the case, actually, some are, some aren't ;) Point is that the Packman packages are either more recent or more feature complete, mostly wrt codec support. Just to clarify, as you seem to imply we're doing some sort of virtual comparison of male organs here.
That our solver doesn't make it easy is a clear problem though.
Indeed. But I suppose there aren't any changes that it gets fixed before 10.3 GM, so we'll have to try to find some ugly hack to work around it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=310455#c29
Stanislav Visnovsky
https://bugzilla.novell.com/show_bug.cgi?id=310455#c30
--- Comment #30 from Benjamin Weber
Patch doesn't do what it's intended to do. I've no idea why but libzypp thinks the architecture is changing when the vendor comparison returns true.
My bad, I think I was hitting another bug here. It does seem to disable the vendor change warning in most cases. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=310455
User schubi@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=310455#c31
Stefan Schubert
participants (1)
-
bugzilla_noreply@novell.com