Re: RFC: Policy 10.1 and appropriateness of package conflicts
Andreas Tille writes ("Re: RFC: Policy 10.1 and appropriateness of package conflicts"):
> On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
> > 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.
So the only purpose of "fsl" is to provide these namespace-eating
convenience symlinks ? If so I'm not sure that this is a good purpose
for a a package.
Rather, unconditionally install the convenience symlinks but in a
dedicated directory which users can put on their PATH. Amongst other
benefits, that will mean that the namespace clash can be resolved on a
per-user basis.
> > 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).
I think you've misunderstood Michael's situation. The package works
fine without having to rename anything. So there is no need for
wrapper scripts to set PATH.
I agree that such wrapper are a reasonable approach for troublesome
packages which do actually need to refer to bits of themselves by
namespace-eating names, although they're a bit of a kludgey solution
(and don't work properly if the package allows the user to shell out).
Ian.
Reply to: