05:05:01,141 ERR anaconda: package conflicts: upstart-sysvinit conflicts with systemd-17-5.fc15.x86_64
05:05:01,142 ERR anaconda: package conflicts: systemd-sysvinit conflicts with (installed) upstart-sysvinit-0.6.5-9.fc14.x86_64

I believe this is the same issue reported in bug#676815

Can you repeat the test, while enabling updates-testing so it pulls systemd-18-1.fc15 (https://admin.fedoraproject.org/updates/systemd-18-1.fc15) into the transaction.

*** This bug has been marked as a duplicate of bug 676815 ***

Apologies, I hastily closed this issue.  Upon closer inspection, there are other package failures listed besides the systemd conflict.  If memory serves, the installer ignores dependency problems on upgrade, but recognizes package conflicts.  I hope that's the case, otherwise we have a *lot* of package dependency bugs that will need to be resolved for upgrade to work.

In order to proceed with the remaining package issues, I think we'll need clarification from the installer team on how package dependencies are handled on upgrade.  If they are ignored, then a bug against anaconda may be in order (since it is not ignoring them).  If they are recognized, then a bug against *each* src.rpm that has dependency problems will be needed.  That will be a *lot* of bugs :(

Reassigning to 'anaconda' and adding 'clumens' to the cc for some insight.  Chris, any thoughts?

According to clumens, this could be a behavior change with the new rpm-4.9 in Fedora (https://fedoraproject.org/wiki/Features/RPM4.9).

10:34:27  clumens:         if self.anaconda.upgrade:
10:34:28  clumens:             self.ts.ts.setProbFilter(~rpm.RPMPROB_FILTER_DISKSPACE)

@Panu - Any thoughts on changes that might have altered this behavior?

Hum. Problem filtering never allowed filtering out conflicts, so that shouldn't be an issue. The dependency checking code did see a whole lot of changes in 4.9.x so its a possibility something there is misfiring ... but in general, conflicts are conflicts and if anything, it'd probably be yum that should be figuring a way out of them.

Do you have a log of what is being triggered as conflicts so I can get a better idea what's going on?

(In reply to comment #4)
> Do you have a log of what is being triggered as conflicts so I can get a better
> idea what's going on?

Hi Panu.  Does the end of attachment#479624 [details] have the level of detail you are looking for?

05:04:26,327 INFO anaconda: Preparing to install packages
05:05:01,141 ERR anaconda: package conflicts: upstart-sysvinit conflicts with systemd-17-5.fc15.x86_64
05:05:01,142 ERR anaconda: package conflicts: systemd-sysvinit conflicts with (installed) upstart-sysvinit-0.6.5-9.fc14.x86_64
05:05:01,142 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by gnome-pilot-2.32.0-4.fc15.x86_64
05:05:01,143 ERR anaconda: required package: libgucharmap.so.7()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,143 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by (installed) gnome-python2-applet-2.32.0-1.fc14.x86_64
05:05:01,143 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by (installed) libpanelappletmm-2.26.0-2.fc12.x86_64
05:05:01,144 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,144 ERR anaconda: required package: libpanel-applet-3.so.0()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,144 ERR anaconda: required package: system-config-network-tui = 1.6.1-1.fc14 is needed by (installed) system-config-network-1.6.1-1.fc14.noarch
05:05:01,144 ERR anaconda: required package: policycoreutils-python = 2.0.83-28.fc14 is needed by (installed) policycoreutils-gui-2.0.83-28.fc14.x86_64
05:05:01,145 ERR anaconda: required package: setools-libs = 3.3.7-7.fc14 is needed by (installed) setools-console-3.3.7-7.fc14.x86_64
05:05:01,145 ERR anaconda: required package: libgweather.so.1()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,145 ERR anaconda: required package: libnotify.so.1()(64bit) is needed by (installed) krb5-auth-dialog-0.16-1.fc14.x86_64
05:05:01,146 ERR anaconda: required package: libnotify.so.1()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64

Ok so the only actual conflict was the systemd thing which as already been fixed by obsoleting upstart (bug 676815). The rest look like simply real, broken dependencies in the repository (looking at the curren branched-reports, there are TONS of broken dependencies around libpanel-applet and friends so no big surprise). In other words, those packages need fixing.

Or is anaconda actually supposed to continue despite such broken dependencies, but doesn't do so with rpm 4.9.x?

On upgrade, anaconda should catch the broken dependency case and keep going I believe.  On install, it should catch this and offer to let you change package selections, exit, or continue.  Upgrades don't get that choice because there's no package selection.

I retested this upgrade issue last week, with kickstart and a custom repository that included the proper systemd packages.  The installer still stopped at broken dependencies.

Bug#678321 tracks an issue related to the empty error dialog, but the attachment on that bug has additional logs showing dependency problems on upgrade.

Created attachment 480360 [details]
Wipe out pre-existing problems before transaction

Ahhat, I see where the difference in behavior with rpm 4.9.x comes from... This is just another characteristically convoluted rpm issue (sigh)

Older versions silently wiped out any pre-existing problems in the transaction at the start of ts.run(), regardless of whether they could be filtered or not, and ts.setProbFilter() never supported filtering out dependency problems. The assumption is that if you call ts.check(), you care about its results - there's no poing calling it if you dont, so "normal" callers dont hit this issue at all.

I'll need to consider whether to make 4.9.x behave like older versions in this corner-case, but the attached patch should fix the issue here, and as an added bonus, save a bit of memory (nothing too dramatic but a few megs anyway on larger installs).

Hrmph, bugzilla seems to mangle patch attachments, making a mess out of git-format-patch generated patch comments :-/

Anyway, in addition to the above patch, you might want to consider one of these

1) don't bother calling ts.check() at all on upgrades, since we dont care about the results
@@ -1004,7 +1004,8 @@ class AnacondaYum(yum.YumBase):
             else:
                 return DISPATCH_BACK
 
-        self.ts.check()
+        if not self.anaconda.upgrade:
+            self.ts.check()
         self.ts.order()
         self.ts.clean()
 
2) always call ts.check(), but (optionally) let upgrade continue despite problems (more of a pseudo-patch):
@@ -1005,6 +1005,13 @@ class AnacondaYum(yum.YumBase):
                 return DISPATCH_BACK
 
         self.ts.check()
+        if self.ts.problems():
+            if self.anaconda.upgrade:
+                # let user know there are problems and choose to continue
+                # or abort?
+            else: 
+                # on install we should bail out right here, although this
+                # is unlikely to happen
         self.ts.order()
         self.ts.clean()

Looking at just the minimal patch from comment #9, James - can you retest with the F15 alpha containing anaconda-15.20.1-1 and updates=http://clumens.fedorapeople.org/678201.img?

Panu - thanks for the patches.  Much appreciated.

(In reply to comment #11)
> Looking at just the minimal patch from comment #9, James - can you retest with
> the F15 alpha containing anaconda-15.20.1-1 and
> updates=http://clumens.fedorapeople.org/678201.img?

Seems to do the trick.  Tested upgrades from F-14-i386 @base and F-14-x86_64 --default.  No conflicts dialogs were presented.

The pre-upgraded F-14-x86_64 was exposed to the same potential dependency conflict (libpanel-applet) noted earlier, and I was not prompted about the problem while using the updates.img.  I'll review the system post-upgrade, but this appears to do the right thing.

Confirmed, there were package dependency problems present on the post-upgraded systems.  Those were resolved by packaged in updates-testing, but the good news is that the updates.img seems to have worked.  Good bug report Hongqing, thanks all!

Proposing for F15 Beta since this blocks the following criteria:

"The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually "

https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria

I'll consider the patches in comment #10 for post-f15, but for now I'm only pushing the minimum amount required to fix the problem.

*** Bug 680820 has been marked as a duplicate of this bug. ***

*** Bug 680851 has been marked as a duplicate of this bug. ***

reproduced in fedora 15 alpha rc2.

Created attachment 481482 [details]
F-15 Alpha RC2 anaconda log

The duplicate bug 676815 has been closed as Errata.

(In reply to comment #20)
> The duplicate bug 676815 has been closed as Errata.

Let's keep this bug open until a new anaconda is built that includes the anaconda fix to ignore package deps/conflicts on upgrade.

Fix included in anaconda.git, will be in next F-15 anaconda build.

http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=18d0b27146ffe328df9ace3984d601ad7bac19c6

Discussed at 2011-03-11 blocker review meeting.  This issue is fixed and available for testing in anaconda-15.21-1.  The issue has been accepted as a beta blocker.

anaconda-15.26-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/anaconda-15.26-1.fc15

Package anaconda-15.26-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-15.26-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/anaconda-15.26-1.fc15
then log in and leave karma (feedback).

anaconda-15.26-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.