(In reply to comment #0)
> Description of problem:
> 
> To prevent a missing-dependency problem, I want to install everything locally
> available, even what I wouldn't otherwise want. I now do that by selecting
> manually. I want that automated, to prevent errors.
> 

Installing everything will not solve dep problems.  If there is a dep problem it should be addressed per package in the spec file of the package.

What dependency package are you referring to?

As you have illustrated in your bug report, one of the big problems with the Everything install is that everyone has their own definition of it.  Your definition does not include languages or remote repos.  However it does for other people.  And not including remote repos is especially problematic on installs started from a boot.iso, as they'll all be remote.  It's very confusing to have a UI option do completely different things depending on what boot media you are using.

Everything installs are simply not something that we're interested in supporting anymore given the UI problems, dependency problems, etc.  You've already outlined a half dozen problems and potential inconsistencies in describing the kind of Everything install you're interested in.  As you can see, supporting this option and explaining exactly what it does in the limited UI space is pretty tough to do.  This has been discussed pretty thoroughly in bug reports and mailing list threads in the past, though some of the bug reports get pretty nasty.

As a bit of a compromise, you can do %packages * in kickstart or you can right click on package groups in the right pane of the package selection UI and select all from the group so there are fewer clicks required.  So there is some limited support for this, but we really don't want to make it as straightforward as just selecting a single checkbox as that gets into the problems outlined above.

For what it's worth, everything installs are broken at the moment due to file conflicts, and have been since at least F9. Even if there was an everything button, and there isn't and won't be, using it would break your install.

I agree with much, which is why I've replaced the summary (title).

The above boil down to one problem serious enough to damage installations regardless of how components are selected, e.g., individually or en masse. That suggests that Red Hat and the community need to formulate a better solution. Omitting the Everything checkbox lowers RH's liability but not human installers' liability if they happen to select conflicting software. That latter issue should be addressed, even without an Everything option. 

I'm trying to imagine how programs' dependencies can conflict before chosen execution. All that occur to me are three ways: A conflict is among daemons and the kernel and their dependencies. A program specifies that a file be absent when another program insists it be present. Or, more likely, two programs demand the presence in the same path of the same file but different versions thereof. I don't understand why a program should legitimately demand a file be absent. I do understand a clash of versions, since a later version may drop a needed function (feature, method, call, etc.) or be faulty.

All these cases can be seen as being due to erroneous programming in the calling program being installed. That should be ground for dropping the program from a Red Hat-supported distro or spin. An alternative is reprogramming the particular program to handle either case of erroneous programming (except the kernel, as everything else should be designed around the kernel).

A requirement that a file be absent could be satisfied by creating a new folder from which the file would be absent regardless of whether another program installs the file in a traditional location.

Requirements for different versions of the same supporting file with the same name in the same path could be satisfied by creating a new path for one and calling to it there.

Since the solutions exist, maintainers of offending programs should be encouraged to implement them. Should they not but should RH want the software anyway despite clashes of dependencies, at least tell us humans who install which two programs clash in this regard, even if only one of them is in any repository or spin. If we question whether to install both of them on one system, we may keep computer run-time problems down.

A list of conflicting programs would be helpful. It may be online. Better would be to copy that list or a subset to the installer disc, so it'll be available to an installing human without online access (same-machine online access is dangerous during a clean install).

Chris' critique identifies problems of boot-media differences, choice popularity, and in-UI description. None is all that difficult. Use of different boot media is not that confusing, because if anaconda senses the type of media it can simply present the choices appropriate to it. If an Everything option can be omitted from all boot-media contexts, it can be omitted from some boot-media contexts. Only the more common choices need be accommodated, since human installers can customize as they wish, as now. And if a single-word title is inadequate to describe an option, a phrase, sentence, or paragraph is fine, as amply shown elsewhere in anaconda and other contexts. FC4's anaconda, at least, has several panes in which several paragraphs explain something; I don't remember if F10's also did, but a several-paragraphs-long explanation is better than being in the dark, and may be especially useful when Internet access is unavailable during an installation.

I previously installed a past version of Linux (probably FC1 or 4) and chose to omit games because I didn't want any and ran into a dependency problem that was solved by installing games after all. Beyond that, I don't remember the details. Since then, I've always installed everything. Now I see the problem with the Everything option but have no alternative I can implement.

I don't know (re Joel's question) if I have access to dependency specs during an offline install, so I'm not sure that works. If clashes occur from errors in programming, then I'm not sure the original programmers will have been better at writing their specs.

I take it kickstart is only for someone who's installing on many machines. It may be that clicking hundreds of component listings may be no more time-consuming than creating a kickstart file for one single-machine installation (although I can't see F10's kickstart UI now).

So: Can we identify program conflicts and come up with a way for avoidance when we install?

(I couldn't change the status relevantly, although I would because of the revision of the issue's substance, because opening a new bug would sort of bury the prior views of all.)

Thank you.
	
-- 
Nick

No, we cannot. We do dependency solving after package selection because we cannot identify in advance what will conflict. If the installer does not allow backtracking after conflicts are found, well, that should definitely go into the UI rewrite (though I believe it does indeed allow you to go back).

Kickstart is definitely not only for someone who is installing on many machines, and it takes very little time to create - you can even make one that will *only* affect package selection, and allow you to customize the rest of your install by hand, if that's what you'd like. Alternatively, if you're not already doing this, right clicking on group names and selecting "Select all optional packages" will help you save time.

Chris' point about boot media is that we don't want there to be different choices depending on how you install, and an everything install is not something we wish to support.

I've already accepted that Everything should not be pursued, but another solution is needed. Here's one: dependencies (including full paths, versions, and mandatory absences) may be listed for all RH-included or RH-recognized programs in a central database and the db sorted to see which programs seek the same dependencies in ways that may clash (e.g., conflicting versions). I haven't seen dep specs but either they can be used or developers can be asked for the data, perhaps simply given passworded access to their section of the database so they can update it themselves.

Going back in the installation is allowed but doesn't help until a conflict is found or suspected. After the installing is done, Add/Remove Applications or similar will help, but only if we can figure out the likely offender for testing by absence.

If we do find or suspect a conflict, I don't know of a central place to report it. Telling one developer may result in nothing, since they may feel that it's not their problem but the other party's (who may not agree), and while many are willing to announce the existence of problems there's no consistent format for doing so and we'd have to examine potentially hundreds of sites. Compared to that, a central db would be a major relief.

The ks.cfg process is interesting, and even in F10 it may include an @everything line (or so says the book I'm using), but that line would incur the same problem you described for the GUI anaconda (perhaps you should disable @everything when a kickstart file runs, unless the book is wrong). Indeed, the problem with @everything may be true of any package group (e.g., @editors), unless RH-listed groups have already been researched or tested against any possible dep conflicts and the @everything hasn't been. I may look into kickstart more.

I don't recall right-clicking being mentioned inside the installer. Maybe I missed it, unless anaconda doesn't mention it. If it doesn't, could you add a mention to future anaconda versions?

Another kind of conflict between packages occurred to me: one that results when a program rarely needs a certain  dependency and so it isn't mentioned in the spec. In that case, the conflict may not manifest for weeks or months, making diagnosis that much harder. That's still erroneous programming, since, I assume, the spec should list all dependencies however rarely relevant.

A database should include all deps including the rarest.

Thanks.

-- 
Nick