When installing software in different ways, at different times, and from different sources, conflicts between filenames and even versions of the same common files (helpfully included by the packager) can and do occur. This article is intended to provide some background on these issues and how ANPM tries to avoid them when installing new RPM packages.
On this page
ANPM’s conflict detection feature
When selecting one or more packages to be installed, updated, or reinstalled from a repository, or when selecting a package for downgrade (Get specific release), ANPM runs a DLL conflict detection routine.
Conflict detection searches for DLLs already loaded in memory as well as those which are locatable in LIBPATH against names of DLLs in the selected package(s). If any are found with filenames identical to those which are to be installed, the DLL Conflict dialog is presented in front of the Download Package(s) dialog. See below for more details on how the conflict logic is applied.
The DLL Conflict dialog lists the existing file, including its full path, the new file to be installed which will conflict, and the package in which the new file is located. Clicking OK will cancel the installation operation (even where other packages containing non-conflicting files have been selected). Clicking Ignore accepts the conflict, and dismisses the dialog. This may result in unpredictable behavior after installation of the package containing the conflicting DLL(s). Conflict resolution is left to the user, and no single resolution fits all possible conflicts.
Conflict detection logic
Conflict detection considers the following:
- Is a DLL present in memory with the same name as a DLL to be installed?
- Can a DLL be found in the current LIBPATH and loaded with the same name as a DLL to be installed?
In either of the above to cases, the conflict dialog will be presented. Note that the target location for the DLL to be installed is not considered, here, as it is possible that a given package may append the target directory to LIBPATH, thus causing a conflict which might not otherwise exist. Matching is not case-sensitive.
When conflict detection is performed
Conflict detection is performed when installing a package from a configured repository, as well as when reinstalling, updating, and downgrading (Get specific release). To be more precise, if a conflict is detected, the DLL Conflict dialog is presented in front of the Download Package(s) dialog. The absence of the DLL Conflict dialog is not an indication that conflict detection was not performed, only that no conflicts were detected.
Conflict detection is not triggered when installing a package from file.
Conflict detection is triggered whether or not the file has already been cached locally.
Conflict ramifications
It is hard to predict the behavior which may result from conflicting DLL names being present and loadable by a given application. In some cases, this may be completely harmless, particularly when the DLLs are, in fact, the same file and version, just located in two different places. Other than consuming extra disk space, this should hardly matter (until one of the conflicting packages is next updated and perhaps a newer version of the DLL is installed). However, in other cases, a conflict may cause considerable difficulties for the application expecting the other version to be loaded.
Whether the affected application is the one previously installed or the new one is also hard to determine. An application dependent upon an older version of a given DLL may load and perform perfectly with a newer version of that DLL. However, the reverse may not be the case, where the older DLL may be the first found and loaded, and where it does not provide the necessary functions to satisfy the needs of the newer application.
In yet some other situations two completely unrelated DLLs may by sheer coincidence (or poor planning on the part of a developer) have exactly the same name and thus contain very different functions, each not useful to the other’s calling application(s).
In short, conflicts should be avoided whenever possible, and when unavoidable, steps must be taken to ensure the proper one is loaded by its calling application.
Possible resolutions
In some cases, conflicts may be resolved by moving the existing DLL to a location which is not in LIBPATH (e.g., the program directory of the application using that DLL). In other cases, judicious use of LIBPATHSTRICT may be appropriate.
Perhaps some reordering of the current LIBPATH is all that may be needed to ensure that the proper version is located first.
In cases where the DLL to be installed by a selected package is unfamiliar, it may be necessary to perform the install, examine the new file (check its bldlevel, size, MD5 checksum, etc.) and make a proper determination as to whether it actually does conflict (not all files named something.DLL are, in fact, DLLs).
Determine the source of the existing DLL
The existing DLL may have been installed as part of a larger package. Perhaps that dependent application is the only application on the system to need that package. This may be a candidate for testing an updated version (if it can be determined that the conflicting DLL to be installed is indeed an “update” to the installed version).
Is the existing application really needed? In some cases, conflicts may occur with applications which are no longer being used, but which were never uninstalled. Take this opportunity to reclaim some disk space and perform some basic housekeeping.
Perhaps the original application has been updated, and the new package has done away with including the DLL altogether in favor of having it supplied by another package (such as the RPM to be installed). This is another opportunity to ensure that the system software is up to date.
This entry last updated: by