Bug 34052 - forbid multiple pkgs providing the same thing (at least, for libs)
: forbid multiple pkgs providing the same thing (at least, for libs)
Status: NEW
: Sisyphus
(All bugs in Sisyphus/apt)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2017-10-23 16:10 by
Modified: 2017-10-29 16:41 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2017-10-23 16:10:26
(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.)