I know this is a long shot, but Amarok 2.0.2 segfaults interminably, consumes resources like the world's gonna end tomorrow, and causes data loss for people migrating from Amarok 1. More here: http://rudd-o.com/en/linux-and-free-software/amarok-2-a-story-of-disappointment In there are working, tested RPM packages of Amarok 1.4.10 that should work fine when installed on F11 systems (I'm using it in Rawhide right now). They have a couple of patches to let them build against the newer lib versions that F10 and F11 ship. Now I know yum doesn't support downgrading of packages, so the strategy could either be to publish the 1.4.10 RPMs to the repos and noting that they can be downgraded manually, or... well, yum experts speak, I myself use smart and smart has no problem letting me downgrade packages intelligently.
feel free to raise the issue on the fedora-kde list, and we can discuss options. But, bugzilla is not a forum for such discourse.
For your third-party packages: Rename your packages to amarok1, and if it really cannot coexist with Amarok 2, use a Conflicts tag, that'll make things easier for users wanting to use your packages.
1. I was told to raise a bug here in #fedora-qa 2. Sorry, I cannot subscribe to a mailing list just to raise one point. I already wade through thousands of mails daily. 3. I can certainly see the benefits of adding a conflicts: tag to inform RPM depsolvers a priori that they cannot be parallel-installable, and I could even work on making the files themselves parallel-installable, but why would I rename the package? It's not my fault Yum cannot handle package installation of older packages -- Smart PM can. Thus I don't see why I would need to encourage the continued reliance on broken software when good alternatives exist.
In about 15 minutes the package with the conflicts: tag will be uploaded. Feel free to take from there if you want to proceed further with my suggestion -- and, if not, well, as they say, worksforme.
1. It's not a bug, Amarok 2 is intentionally included, it is considered a stable release by upstream and they are expecting distributions to package it. FWIW, I also don't think you'll get far if you raise this point on a mailing list. Reverting now that F10 has been released with Amarok 2 already is not really an option, also because there's no support for migrating settings backwards. 2. See above. 3. The Conflicts: tag ONLY makes sense if you rename the package. It doesn't make sense to have a package marked as conflicting with another version of itself. (It is obvious that it will conflict, except for the kernel which is special-cased practically everywhere.) 3'. You should rename the package because that way your users can install it without getting it replaced by the Amarok 2 package in Fedora on automatic upgrades (even with smart, unless they manually configure it to pin your specific version). (Another approach would be to bump Epoch, but then they'll be stuck with Amarok 1 forever unless we also bump it, which we have no intention to do because then we'd end up in an Epoch war with people wanting to keep Amarok 1 forever. Having the packages named differently allows the user to choose.) 3". Let's face it, yum (and tools built on yum such as PackageKit) is the default package dependency resolver in Fedora, it should be the primary focus of all packaging. Now I'm not saying the packages should not ALSO work with smart and apt-rpm, but requiring their features for them to work at all is really a no-go. Now a user can also add manual exclude=amarok lines to the yum .repo files, but once again that's manual configuration. Packages should just work without manually configuring the dependency resolution tools.
In re 1.: You'll note that "considered a stable release" was an egregious mistake in which you were unfortunately caught. I already said "I know that this is a long shot" as well. As for back-migrating settings, both amarok1 and amarok2 work OK with the same config file -- it's just the collection that is stored in different ways (but compatible with parallel-install). In re 3.: Users using a non-braindead package manager can choose to install Amarok 1 without the need for the rename (the Conflicts: tag does help there) and pin it. You can also upload Amarok 1 to your repositories even with its current name and no harm would take place. I do not advocate for epoch bump either. I certainly do not want to make users of Amarok 2 downgrade to Amarok 1 automatically -- at no point have I ever advocated this nor should anything I said be construed to mean that. Continuing: PackageKit already has a Smart backend. I'm not proposing you change to Smart wholesale, but now that the pieces are available, it would be a worthwhile consideration for future releases. In short: I don't find this "renaming" practice good and the package works as-is just fine. Users can click it on the GUI of their Smart package manager and it gets installed, after which -- of course -- they can pin it if they want to prevent its upgrade. Your depsolver software ought to cope with this possibility instead of forcing the insane Debianization of your repos (libabc1, libbcd2, openssl09648484) and the incalculable labor that it is causing now. It would also be worthwhile if your depsolver software allowed the user to install "obsolete" versions of their favorite software and inferred that the user does not want the package to be automatically upgraded. If your depsolver software did this (Smart already does half of it), you'd be one step closer to inter-distro compatibility.
(I think we both know renaming the package is really a workaround for a deficiency in the depsolver, don't we? Our debate here is nothing but a digression on whether to resort to that workaround or find a long-term cure for the deficiency.)