(This is related to the issue of having alternative Provides in Sisyphus overall.) Consider the argument about libs first, but this can be generalized to other relevant things in the list of Provides, too. Usually, having installed sevaral pkgs providing the same libfoo.so.N (restricted to 32 or 64bit and to the default system paths for libraries) means the system is broken (i.e., doesn't work as expected): one instance of the lib won't be used. (Apart from libs, the same argument would be valid for python3(foo); restricted to the default system path for Python3 modules; etc.) Quite often this would also mean a plain file conflict. And this happens often indeed: the corresponding formal Conflicts are not declared. A recent example: # apt-get update && apt-get install gst-plugins-ba{se,d}1.0 Reading Package Lists... Done Building Dependency Tree... Done Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: gstreamer1.0 libgst-plugins1.0 libgst-plugins1.0-gir libgstreamer1.0 libgstreamer1.0-gir liblrdf libraptor2 libvulkan1 libwebp7 libyajl The following packages will be upgraded gst-plugins-bad1.0 gst-plugins-base1.0 gstreamer1.0 libgst-plugins1.0 libgst-plugins1.0-gir libgstreamer1.0 libgstreamer1.0-gir The following NEW packages will be installed: liblrdf libraptor2 libvulkan1 libwebp7 libyajl 7 upgraded, 5 newly installed, 0 removed and 273 not upgraded. Need to get 0B/5024kB of archives. After unpacking 2268kB of additional disk space will be used. Do you want to continue? [Y/n] Committing changes... Preparing... #################################################################################################### [100%] file /usr/lib64/libwebpdemux.so.2 from install of libwebp7-0.6.0-alt0.M80P.1.x86_64 conflicts with file from package libwebp6-0.5.1-alt1.x86_64 E: Error while running transaction # rpm -q apt apt-0.5.15lorg2-alt57.x86_64 # Such an APT "policy" would also help to correctly perform all such upgrades (with undeclared conflicts). In a sense, it would "fix" these packages "dynamically" (at the time of apt-get install). Previously, I have been thinking about auto-generating such conflicts by extending rpm-build with find-conflicts (similar to find-{requires,provides}), but I like this blowing up of static pkglists for APT less than the suggested "dynamic" approach; unlike usual Requires/Provides (which are unique information which can be derived only from the package contents), this kind of Conflicts can be derived just from the known Provides. APT already has a similar restriction for multiple packages with the same name. (Packages with the same name are not allowed to be installed simultaneously, and are detected by apt-get check.)
