#116 Clarify https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts to say that explicit Conflicts: are acceptable
Closed: Fixed None Opened 13 years ago by adamwill.

= bug description =

Please update the https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts test case to clarify that explicit Conflicts: tags are okay.

= bug analysis =

The relevant release criterion is "No file conflicts or unresolved package dependencies during a media-based (CD/DVD) install". The term "file conflicts" here is important. I believe it's intended to mean that only cases where the files in two packages conflict, but there is no explicit Conflicts: tag in the packages. Where the conflict is properly marked in the packages with Conflicts: tags, this should not be considered an infringement of the criterion.

= fix recommendation =

Change expected results:

  1. No file conflicts were detected for packages included in the media kit, unless the conflicting packages also have explicit Conflicts: tags

Replying to [ticket:116 adamwill]:

= bug description =

Please update the https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts test case to clarify that explicit Conflicts: tags are okay.

= bug analysis =

The relevant release criterion is "No file conflicts or unresolved package dependencies during a media-based (CD/DVD) install". The term "file conflicts" here is important. I believe it's intended to mean that only cases where the files in two packages conflict, but there is no explicit Conflicts: tag in the packages. Where the conflict is properly marked in the packages with Conflicts: tags, this should not be considered an infringement of the criterion.

= fix recommendation =

Change expected results:

  1. No file conflicts were detected for packages included in the media kit, unless the conflicting packages also have explicit Conflicts: tags

That makes sense, I've updated the case. Thanks, Adam.

Reopening, I have a question. Will the 'potential_conflict.py' script be accommodated for the new behaviour (i.e. ignoring conflicting packages that have Conflicts: tag) - or - should we check that manually?

I don't know who can answer about the former case, skvidal and jkeating are written as the authors of the script, maybe we can ask them? Adding to CC.

If the latter case is true we should definitely add some guidelines to the test case that describe how to check those Conflict: tags.

I think we could stand to re-assess the desired behaviour here.

Rui, James - are you aware of exactly how the installer behaves in all conflicting package cases? We have a few things to establish here:

  • What does anaconda do if packages within any of the pre-defined install groups have undeclared file conflicts?

  • What does anaconda do if packages within any of the pre-defined install groups have declared conflicts (Conflicts: tags)

  • What does anaconda do if you manually select conflicting packages in the package selection interface - both declared and undeclared cases?

I think we should have the answers to those questions before deciding exactly what our criteria for conflicting packages on the media ought to be...

Replying to [comment:4 adamwill]:

I think we could stand to re-assess the desired behaviour here.

Rui, James - are you aware of exactly how the installer behaves in all conflicting package cases? We have a few things to establish here:

  • What does anaconda do if packages within any of the pre-defined install groups have undeclared file conflicts?

How do you mean "pre-defined"? Do you mean comps.xml groups, or the install groups shown on the reposetup step in the installer (Desktop, server, minimal etc...). I suspect you mean the list of install variants/flavors on the reposetup installer screen.

As of FC13 (from what I recall), package dependency errors are presented to the user, the user can ''ignore'', or go ''back'' to change package selections. Package conflicts are treated similarly.

File conflicts are also presented to the user, but they cannot be ignored. The user must return to the package selection screen and manually resolve the conflicts.

I don't believe any of the behaviors changes whether the conflicts/deps are present in the repostep package groups, or during manual package selection.

  • What does anaconda do if packages within any of the pre-defined install groups have declared conflicts (Conflicts: tags)

  • What does anaconda do if you manually select conflicting packages in the package selection interface - both declared and undeclared cases?

I think we should have the answers to those questions before deciding exactly what our criteria for conflicting packages on the media ought to be...

Adding clumens and jwrdegoede to the cc list (anaconda-devel). As anaconda-devel, they're in a much better position to providing accurate answers. My understanding of how this is handled (and test results) are listed above.

To confirm the actual behavior, I updated my http://jlaska.fedorapeople.org/repotest/fc14 (based on rhe's work) to include 2 packages that conflict with each other, and 2 packages that contain file-conflicts, and 1 package with an unresolved dependency.

As of FC13 (from what I recall), package dependency errors are presented to the user, the user can ''ignore'', or go ''back'' to change package selections. Package conflicts are treated similarly.

File conflicts are also presented to the user, but they cannot be ignored. The user must return to the package selection screen and manually resolve the conflicts.

I don't believe any of the behaviors changes whether the conflicts/deps are present in the repostep package groups, or during manual package selection.

This is mostly correct. If packages have conflicts, I believe rpm will raise a rpm.RPMPROB_CONFLICT, which anaconda will catch and display just like any other rpm error. This means it gets handled the same way as file conflicts, disk space, and some bizarre seldom-seen error conditions. You'll get the dialog telling you to go back and change package selections.

  • What does anaconda do if packages within any of the pre-defined install groups have declared conflicts (Conflicts: tags)

  • What does anaconda do if you manually select conflicting packages in the package selection interface - both declared and undeclared cases?

In these two cases, it should act as I described above - the same way as file conflicts, basically.

Thanks. So I could add how to check Conflicts:tags and what anaconda is supposed to behave for such declared Conflicts(The user is prompted with a dialog indicating go back and change package selections) to the expected results.

I can't claim for sure what the intended behaviour of potential_conflict.py script is, but I suppose we could just modify it, couldn't we? I believe the intent is to show "bad"/"broken" package and file conflicts. If two packages contain Conflicts tag against each other, then that is quite OK from my point of view and potential_conflict.py should not print them. If we modify the script then we don't have to check for Conflicts tags by hand.

Or maybe the script may print such packages, but mark them as "conflicting, but well created".

When originally drafted long ago, the intent for the criteria (and test case) was to ensure that no conflicts/dependency dialog is presented to the user for any packages that they can install from media. Dependencies and conflicts (pkg and file) used to be non-recoverable events during installation. That is no longer the case. However, I do think it's important to the user experience that the user should not be prompted for packaging/mash/pungi for content on the media kit.

As I understand it, even if packages are setup with proper a %conflicts:tag, they still conflict and will prompt the user for feedback if 2 conflicting packages are included in a transaction. The case with upstart and systemd is special in that they are not selectable during package selection, but are available during kickstart.

Are we now comfortable with allowing a prompt for package conflicts on the media for certain types of conflicts?

I think I agree with James here, so I'd rather like to re-present my proposed criterion change to cover this. The criterion would be re-phrased as:

No packages on the split CD or DVD images that are in any way available for selection during an interactive install may conflict with each other.

Replying to [comment:10 adamwill]:

No packages on the split CD or DVD images that are in any way available for selection during an interactive install may conflict with each other.

How do we check "available for selection"? We can't crawl through all the package lists to see whether a package is available for selection or not.

Replying to [comment:9 jlaska]:

Are we now comfortable with allowing a prompt for package conflicts on the media for certain types of conflicts?

I think when the conflicts are properly defined (that means using RPM Conflicts tag), there's nothing wrong with it. We should be able to have two mutually exclusive alternatives for some tool available on the media (why not?). The best user experience would be if anaconda displayed a warning dialog right away in custom package selection. But showing dialog after custom selection is complete is satisfactory too.

Of course no package conflicts dialog should be shown for the pre-defined install groups (Desktop, Server, Minimal, etc). That should be covered in a test case.

As a point of reference, but perhaps not relevant here's the packaging Guidelines for conflicts:
https://fedoraproject.org/wiki/Packaging:Conflicts

Summary: file conflicts are always a bug to be fixed and should be fixed ASAP.

Explicit Conflicts are almost always a bug to be fixed but leeway for fixing it exists.

kparal: "How do we check "available for selection"? We can't crawl through all the package lists to see whether a package is available for selection or not."

For the groups that you can pick during install (where you pick 'desktop' or 'minimal' or whatever), simple - just do an install and try picking each.

For manual package selection, I'm told only packages listed in comps and marked as 'visible' are available there. It should be trivial to generate that list and compare it against the list of packages we find are conflicting.

Replying to [comment:13 adamwill]:

kparal: "How do we check "available for selection"? We can't crawl through all the package lists to see whether a package is available for selection or not."

For the groups that you can pick during install (where you pick 'desktop' or 'minimal' or whatever), simple - just do an install and try picking each.

For manual package selection, I'm told only packages listed in comps and marked as 'visible' are available there. It should be trivial to generate that list and compare it against the list of packages we find are conflicting.

This seems like non-trivial work for what should be a trivial test. As Toshio points out, leeway for fixing explicit conflicts exists. In this case, leeway was granted since systemd and upstart aren't expected to exist on the media come F-14-Final. As I understand it, they are both present now as a temporary measure to ensure there is a fallback while systemd is tested.

I recommend we don't change the test, but we continue to report this failure with the goal of correcting the problem at some point during the F-14 release. I'd rather not go through large hoops to adjust the conflicts test for something that has been granted temporary leeway.

They're both 'present' in the sense of 'present in the repos' as a temporary fallback measure, yes. They're both 'present' in the sense of 'present on the media' because of how pungi works (AIUI) - we don't actually really want/need both on the media, but they get pulled in because they both satisfy a dependency of upstart, and pungi pulls all packages that can possibly satisfy a given dependency.

I'm fine with continuing to test for all conflicts if you think that's easier, and we can evaluate whether they're actually release blockers on a case-by-case basis. But we should adjust the criterion.

Replying to [comment:14 jlaska]:

I recommend we don't change the test, but we continue to report this failure with the goal of correcting the problem at some point during the F-14 release. I'd rather not go through large hoops to adjust the conflicts test for something that has been granted temporary leeway.

Agree, if file conflicts are always a bug as toshio pointed out, but the release level need be modified with the criterion.

Replying to [comment:15 adamwill]:

I'm fine with continuing to test for all conflicts if you think that's easier, and we can evaluate whether they're actually release blockers on a case-by-case basis. But we should adjust the criterion.

Alright, if we do it like this, then the proposed criterion change is fine. We will also need to revert the test case description to the previous version.

Replying to [comment:17 kparal]:

Replying to [comment:15 adamwill]:

I'm fine with continuing to test for all conflicts if you think that's easier, and we can evaluate whether they're actually release blockers on a case-by-case basis. But we should adjust the criterion.

Alright, if we do it like this, then the proposed criterion change is fine. We will also need to revert the test case description to the previous version.

Of course, changed already.:)

I recalled that as a result, we agreed not to change the test case and keep it the same as before. Therefore close this ticket.

Login to comment on this ticket.

Metadata