> > # conflicts are not appropriate for conflicts between executable names > > reopen 592242
Well, that has been mentioned before and my reasoning is at [0] -- got no comments. I'd be interested in advice what kind of resolution would allow me to close this bug. Renaming the relevant commands makes no sense, because it affects the behavior of the whole FSL toolkit. FYI we are not just talking about the 'imtest' command that caused this bug to be opened -- if one looks at the actual package more conflicts will be obvious. Not to speak about all documentation that is obsolete after a rename. Asking for a rename in the conflicting packages is totally inappropriate: 1. nothing is gained, 2. they are in main and fsl is in non-free, 3. probably breaks even more. IMHO that leaves exactly one solution - not having such a package at all. Which in turn means that FSL users may not have an out-of-the-box setup, because I cannot express a package conflict when there really is one? To reiterate: the 'fsl' package merely installs convenience symlinks of the FSL suite into /usr/bin. The actual commands are installed into a private namespace. FSL is fully usable without the symlinks, after following a documented setup procedure. The sole purpose of the 'fsl' package is to provide people with a working setup without having them to know about that setup. It is quite unlikely that any of the conflicting packages would appear on a real system that runs FSL -- they are typically built to run exactly this suite. I see the point in policy 10.1, but I believe the problem it tries to avoid doesn't exist in this case. I'd be very happy to get comments. Michael [0] http://lists.debian.org/debian-release/2010/08/msg00309.html -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
