Description of problem: Following a successful QA:Testcase upgrade fedup cli Test the resulting system still had several f17 packages and an F17 kernel boot option. This used the F18 wallpaper and screensaver when checked but uname -r was fc17. Version-Release number of selected component (if applicable): How reproducible: Not tested for reproduce Steps to Reproduce: 1. Follow the QA: Testcase upgrade fedup cli testcase 2. When complete and booted into f18 run rpm -qa | grep fc17 3. Attached list will be result Actual results: Several fc17 packages remain - see next atatchment Expected results: No F17 remanants in an upgraded F18 system Additional info:
[bob@localhost ~]$ rpm -qa | grep fc17 smolt-firstboot-1.4.3-6.fc17.noarch system-config-network-tui-1.6.5-1.fc17.noarch ibus-gtk2-1.4.99.20121109-9.fc17.x86_64 libpinyin-0.8.0-2.fc17.x86_64 fedup-0.7.2-1.fc17.noarch smolt-1.4.3-6.fc17.noarch ibus-1.4.99.20121109-9.fc17.x86_64 libfreebob-1.0.11-11.fc17.x86_64 media-player-info-17-2.fc17.noarch libvisio-0.0.24-1.fc17.x86_64 kernel-3.6.10-2.fc17.x86_64 libertas-usb8388-firmware-5.110.22.p23-6.fc17.noarch crash-6.1.0-1.fc17.x86_64 mysql-libs-5.5.28-2.fc17.x86_64 ar9170-firmware-2009.05.28-4.fc17.noarch ibus-libs-1.4.99.20121109-9.fc17.x86_64 kernel-3.3.4-5.fc17.x86_64 ibus-gtk3-1.4.99.20121109-9.fc17.x86_64 libpinyin-data-0.8.0-2.fc17.x86_64 xorg-x11-drv-intel-2.20.16-1.fc17.x86_64 traceroute-2.0.19-1.fc17.x86_64 opus-1.0.2-1.fc17.x86_64 java-1.7.0-openjdk-1.7.0.9-2.3.3.2.fc17.x86_64 [bob@localhost ~]$
Test above was with fedup-0.7.2-1.fc17
[bob@localhost ~]$ rpm -qa | grep fc17 xorg-x11-drv-intel-2.20.16-1.fc17.i686 traceroute-2.0.19-1.fc17.i686 libfreebob-1.0.11-11.fc17.i686 opus-1.0.2-1.fc17.i686 libertas-usb8388-firmware-5.110.22.p23-6.fc17.noarch libpinyin-data-0.8.0-2.fc17.i686 ibus-libs-1.4.99.20121109-9.fc17.i686 ibus-gtk2-1.4.99.20121109-9.fc17.i686 ar9170-firmware-2009.05.28-4.fc17.noarch libvisio-0.0.24-1.fc17.i686 kernel-PAE-3.3.4-5.fc17.i686 media-player-info-17-2.fc17.noarch crash-6.1.0-1.fc17.i686 kernel-PAE-3.6.10-2.fc17.i686 mysql-libs-5.5.28-2.fc17.i686 ibus-1.4.99.20121109-9.fc17.i686 smolt-firstboot-1.4.3-6.fc17.noarch ibus-gtk3-1.4.99.20121109-9.fc17.i686 system-config-network-tui-1.6.5-1.fc17.noarch java-1.7.0-openjdk-1.7.0.9-2.3.3.2.fc17.i686 libpinyin-0.8.0-2.fc17.i686 fedup-0.7.2-1.fc17.noarch smolt-1.4.3-6.fc17.noarch [bob@localhost ~]$
Those are just packages that are newer in f17 updates-testing than in f18, aren't they? I'm not sure there's an actual bug here.
If Adam is correct that the packages I listed then things are really strange, because F17-updates-testing was never enabled, except for the one command to install fedup when I enabled updates-testing for that action only. All packages I installed come from fedora or updates for F17.
Did a bunch of yum info checks today and the packages listed all came from F17-updates and not updates-testing according to yum info. They are a version newer than what is in F18 and F18-updates. So obviously the karma and testing process will resolve the bulk of this issue eventaully. I would still ask why the f17 kernel boot option is left after an update.
(In reply to comment #4) > Those are just packages that are newer in f17 updates-testing than in f18, > aren't they? I'm not sure there's an actual bug here. Actually, it's when packages in f17 updates are newer than what is currently in f18 stable - since we're in freeze, there are a bunch of updates which are still in f18 updates-testing and the problem should go away after release (when the updates repo is populated). You could enable f18 updates-testing during upgrade or update to f18 updates-testing as a short term workaround. This isn't really a bug in fedup but a side effect of how we do releases.
(In reply to comment #0) > Expected results: > No F17 remanants in an upgraded F18 system It's worth noting that this expectation is flawed: there's no policy that requires this, and it's expected to happen in some circumstances. For example: * Packages that have been removed from the distribution * Third-party packages that haven't been updated for the new distro yet There's no automatic way to handle these correctly; some people might want them cleaned up, others might want them left alone. Fedup does non-interactive upgrades; this is interactive, post-upgrade cleanup, which puts it pretty well outside the scope of fedup.
Discussed at 2013-01-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2013-01-02/f18final-blocker-review-8.2013-01-02-17.03.log.txt . Rejected as a blocker: as discussed, all is working as intended here, there is no bug. So let's close this too.