8.5. Dependency Resolving

Dependency resolving is the area where some of the efficiency Revisor can gain for you comes from. While of course there is specific reasons to do things one way, or the other, most people I speak to about Revisor, it is not very clear why, or what Revisor does in this area. First of all, there's two ways of resolving dependencies:

Inclusive Dependency Resolving
Iterate all packages in the transaction and list their requirements, then for each of those requirements, find all packages that provide a matching capability, add those packages to the transaction, and don't forget to add the requirements those packages have themselves, back into the pile of (unmet) requirements.
Exclusive Dependency Resolving
Iterate all the packages and for each of the requirements found, find the best package that meets the requirement. This is also YUMs default behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used during the installation.

8.5.1. Inclusive Dependency Resolving

Hypothetically, you could describe inclusive dependency as follows:

final_packages = []
more_to_do = True
while more_to_do:
more_to_do = False
for package in packages:
    if package in final_packages:
        continue

    dependencies = find_package_dependencies()
    for dependency in dependencies:
        pulled_in_package = pull_in_dependency()
        if pulled_in_package not in final_packages:
            packages.append(pulled_in_package)
            more_to_do = True

So, what does this mean? Basically, it means that if there is a requirement for a capability, all packages providing that capability are being pulled in. Now imagine package 'foo' requires capability 'web-client'. There's a number of packages providing that capability, right? So you get Firefox, lynx, elinks, konqueror, safari, Netscape, Internet Explorer, emacs, for free! All of those pull in their own dependencies also, of course.

Note

If you catch this before it catches you, you can prevent the packages from being pulled in during dependency resolving by not making the package available in the Package Sack in the first place, using the -firefox syntax in the kickstart package manifest, and setting kickstart_uses_pkgsack_excludes to 1.

Note

You may have thought of it; pulling in packages this way may give you a package set (or RPM payload) that has conflicting packages. Imagine package foo requiring capability bar, which is provided by two packages that conflict with one another (either on explicit Conflicts: RPM header or file level). Both will be pulled in, hence disabling you to install everything ('*' or -previously- @Everything in the kickstart package manifest).

8.5.1.1. When This Makes Sense

If you are composing a large distribution of which 3 million users in even so many different situations having so many different expectations and desires, you will want this behaviour, since you won't be able to determine which one of the packages for each capability someone in that group wants, and which one may not want. Or, in case of upgrades, what the system needs. Shipping them all on the same media is the best solution in these cases.

8.5.1.2. When This Does Not Make Sense

When creating installation media to be installed unattended, or to be used in conjunction with deployment strategies
When creating installation media to be upgrading PCs you have controlled from the beginning, such as in a company
Installation for a small group of users or systems
When creating minimal installation media, or media with a minimal RPM payload.
When creating installation media that is to be used with installing "Everything" in the RPM payload.