Re: RFC: Policy 10.1 and appropriateness of package conflicts
On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
> Since renaming is not an option due to large side-effects in the
> packages in question,
In any case educating upstream about this name clash is very important
in cases like this. It's not only about Debian - the name clash might
happen anywhere in the Free Software universe any trigger unwanted side
> 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?
>From what I have read I would regard using a wrapper script which sets
PATH to the directory where the real fsl binaries are residing as an
apropriate solution (as it is for instance done in several other
packages of Debian Med as well).