Samuel Sieb wrote: > On 12/03/2014 07:38 AM, Michael Schwendt wrote: >> On Wed, 03 Dec 2014 08:07:10 -0500, Neal Becker wrote: >> >>> fedup gave me the following warnings: >>> >>> kde-runtime-libs-4.14.3-2.fc20.x86_64 requires exiv2- >>> libs-0.23-5.fc20.x86_64, >>> OpenEXR-libs-1.7.1-6.fc20.x86_64, libgcrypt-1.5.3-2.fc20.x86_64, >>> ilmbase-1.0.3-7.fc20.x86_64, libwebp-0.3.1-3.fc20.x86_64 >> >> Well, I have yet to hear good things about fedup, so take the following >> with a grain of salt. >> > Well then here's one. Fedup works great! I've used it many times with > no problems. > >> # yum list kde-runtime-libs >> Loaded plugins: langpacks >> Available Packages >> kde-runtime-libs.i686 4.14.3-2.fc21 >> updates-testing >> kde-runtime-libs.x86_64 4.14.3-2.fc21 >> updates-testing >> >> This only shows that a "higher" kde-runtime-libs package is available for >> F21, albeit only in the updates-testing repo. Does fedup upgrade to >> updates-testing or just F21 Beta release +/- updates repo? >> > Fedup uses the repo configuration from your current Fedora install. If > you don't have updates-testing enabled, then use: > fedup --network 21 --product=whatever --enablerepo=updates-testing > >> In case it does not, this is typical upgrade path breakage that has >> plagued Fedora for a long time already. You would strictly need to >> upgrade _to_ F21 updates-testing to avoid this. >> >> Upgrading from an up-to-date F(n-1) to F(n) only works well, if every >> package in F(n) is "higher" than F(n-1). That assumption breaks easily, if >> somebody has installed latest updates for F(n-1) [possibly even including >> test updates] but upgrades to something "older", such as a release without >> updates and/or updates-testing. >> > Yes, the issue of the upgrade path breaking around release time is a > very tricky problem to solve. Either use updates-testing or ignore the > breakage (if it's not critical). When the release happens, the updates > will be released and the packages will be generally available. > I don't want to use updates-testing indiscriminatly, because there's no telling what that will drag in. What is needed here, is an option to yum to use updates-testing _only_ to solve broken deps. -- -- Those who don't understand recursion are doomed to repeat it -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
