package conflicts: assemble dependency lists?

[Nick Levinson]

Installing multiple packages risks conflict even before programs run, apparently due to dependencies. For that reason, Red Hat no longer supports an Everything installation. (See <https://bugzilla.redhat.com/show_bug.cgi?id=503880>.) That principle suggests, however, that any two or more pkgs. could conflict, and there are hundreds available just on a DVD, even before counting remote repositories. It could even occur with one package if it has a conflict with the kernel that hasn't been discovered.

Possible problems are dependencies for the same file in the same path but for diifferent versions of the file and mandatory absence of a dependency when another program requires presence.

That leaves a problem when installing. What packages can we install without conflicts? Or how can we fix the conflicts?

As an alternative, I think a public list of dependencies, including mandatory absences of dependencies, would help. The list should start with dep specifications, but if a clash suggests an error in programming, we should allow for error in a dep spec by allowing other people to add corrective observations. Even rare conflicts need to be known.

Is there such a list or is it an inadequate solution or is it bad idea or should it be created?

If it's a good idea, is setting up the list only feasible for distribution engineers or can anyone just start a list? The problem, I assume, is in collecting all the specs that apply to any single spin or more, and I doubt that posting a general message asking .all programmers whose products might be in a spin or a repo will get much response. Is there a better way?

Thanks.

--
Nick

[sonoran]

Originally Posted by Nick Levinson

Is there such a list or is it an inadequate solution or is it bad idea or should it be created?

Hi Nick-
That's what package managers are for.

"yum deplist packagename" will give you a complete list of dependencies. Or, in yumex, using the tabs below the bottom window will provide the same info.

You're absolutely right about the complexity and the potential conflicts. That's why one ought to be careful when going outside the official repositories, and why rpm --force should almost never be used.

Trying to manage a complex system like Fedora from a list, in your head, is a task beyond most of our capabilities. Let yum maintain its database and do the work.

You could always join the yum developers and work on the problem there.

Later--

[Nick Levinson]

Then why do the Red Hat distro engineers have such a problem? What's wrong with installing everything in a spin if I have the hard drive space?

I had proposed that the Everything option be limited (and renamed for truth in labeling) but RH is opposed even to that. I wasn't going to keep this stuff in my head but noted an online list of dep conflicts would allow figuring out which package groups not to install simultaneously. But yum, as described in <http://prefetch.net/articles/yum.html>, seems to handle all that. If yum works as described, and has been run on everything proposed to be included in a spin, then conflicts should have been found by the spin compilers. If dep conflict is why installation does not include an Everything option any more, then the spin must include at least two packages which are simultaneously selectable and and which conflict. Either Everything (if made available again) would work or one or more pairs of packages fail.

Are they assuming that if we select what to install because Everything is no longer an option then we'll be more thoughtful and therefore never select conflicting packages? e.g., that we'll never select to install two browsers because we'll realize how silly that is? But when I look through the list of packages in the spin installation screen no such conflicts occur to me.

Is there a better way to design the installation process for this issue?

Thanks.

--
Nick