RFC: Policy 10.1 and appropriateness of package conflicts
Hi,
I'm trying to figure out a solution for RC bug #592242. The short
summary of this bug is a package A that conflicts with a package B due
to a name clash in /usr/bin. The programs in question do not provide the
same functionality, hence the alternatives systems cannot be used.
Debian policy 10.1 states:
Two different packages _must not_ install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled
via "alternatives" or the "Conflicts" mechanism...)
Since renaming is not an option due to large side-effects in the
packages in question, I declared a package conflict between A and B and
uploaded a new version. However, various parties expressed their
concerns with this "solution".
http://lists.debian.org/debian-release/2010/08/msg00304.html
http://bugs.debian.org/592242 (reopened with reason: "conflicts are
not appropriate for conflicts between executable names")
IMHO this aspect of policy 10.1 tries to prevent the situation of a user
needing the functionality of both packages A and B, but being unable to
install them on the same system, solely due to a filename clash.
However, the situation of #592242 is different. The package (fsl) that
conflicts with other packages (e.g. cyrus-clients-2.2) only installs a
number of symlinks to tools of a large analysis suite into /usr/bin. The
actual suite is installed by another package (fsl-4.1) that does not
conflict with other packages. Hence users will always be able to
install this suite in combination with any other package. The only
purpose of the conflicting package is to allow for a more convenient
out-of-the-box setup for people who run this analysis suite as the
primary software in their research labs. If, for some reason, they happen
to run any of the conflicting packages they can still use the suite with no
drawbacks other than reduced initial setup convenience.
Is there something that is intended by policy 10.1 that I am missing?
Thanks for your comments,
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de
Reply to: