Re: RFC: Policy 10.1 and appropriateness of package conflicts
On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
> 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".
You forgot the rest of the paragraph:
| If this case happens, one of the programs must be renamed. The maintainers
| should report this to the debian-devel mailing list and try to find a consensus
| about which program will have to be renamed. If a consensus cannot be reached,
| both programs must be renamed.
> 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.
I would consider the names of the binaries to generic anyway.
> Is there something that is intended by policy 10.1 that I am missing?
Yes, at least one package have to rename, and this is a must clause.
Bastian
--
Captain's Log, star date 21:34.5...
Reply to: