Red Hat Bugzilla – Bug 503880
install packages: instead of Everything: need a conflict list (see comment 4)
Last modified: 2009-06-04 23:10:59 EDT
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.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start to install.
2. Select components.
Selecting is manual. I wouldn't know if I erred.
It should be encompassed with something akin to an Everything install.
One spin may offer many packages. I think there were hundreds of components to be selected into the software to be installed. Selecting everything when there are that many items is tedious, and it's possible to miss something when many dialogs have to be opened to make sure every component has been checkmarked.
I do not install from online repositories during a clean install, because that would require Internet access before network security is in place, and that risks permanent and undetected damage to my hard drive's contents. So my concern is with what is locally on disc.
An Everything option for whatever is on a given spin reduces entry errors, exposes users to more options long after installing is finished because they're in applications menus, and increases performance when dependencies are assured present. Of course, it has a trade-off of space required, which is why some people won't opt for it, and will choose what they want. But an Everything option should be restored for future versions for software included within a spin. It should not include the contents of off-disc repos.
The risk of Everything installing conflicting software also exists with having no Everything but manually selecting every listed component on the disc if the risk is not identifiable by the installing person. If your engineers identify conflicts, adding them in free-form text to a text file that can be displayed during installation would save us from rediscovering problems.
I'm not clear how a conflict would arise before applications execute. For example, if two apps were run simultaneously and both had to edit the same document (such as a log or an end-use doc) or use the same scarce hardware resource, I assume one program would simply refuse to run until it had the exclusive-write access or machine resources it needed. That doesn't seem relevant to installing.
For an unrelated reason (the lack of root access, discussed elsewhere), I had to wipe F10 off my hard drive and reinstall FC4, which will likely crash irretrievably in some months, so I may eventually reinstall F10 or higher. When I do, an Everything option will be useful.
Features that are wanted:
1. It should be encountered before we encounter the separate software packages.
2. The scope of Everything should be limited to the contents of the spin where it appears, and exclude remote repos. Remote repos being subject to change over time and probably being large and multi-authored, unless repos possess a coordination facility for a disc-based Everything ability, Everything should be limited to the local.
3. Rather than inaccurately calling it Everything, perhaps call it Everything Local.
4. If there's a major difference of opinion on whether it should include foreign-language capabilities, offer Everything Local in One Language and Everything Local in All Languages.
5. If Everything is impossible without causing conflicts and so it must provide only a subset, call it Almost Everything and create a popup box or some such that lists what is excluded and what excluded stuff may conflict with, so the installing person can more quickly make pertinent choices.
6. Selecting ...Everything... should not dim the separate choices (as I think they did in FC4), but merely checkmark/select them. That would allow the installing person to select Everything and then deselect a few components, whereby doing so would promptly deselect Everything per se.
I think this accommodates concerns in Bug 183871.
(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.)
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.