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.