Hi,
On Tue, Aug 10, 2010 at 05:16:30PM -0400, Michael Hanke wrote:
> I see the point in policy 10.1, but I believe the problem it tries to
> avoid doesn't exist in this case.
After some more discussions on -devel I'm now convinced that there is no use in
arguing about closing this bug without further action. As an attempt to
finally fix this bug I'll make a new upload that:
* removes all /usr/bin symlinks from the 'fsl' package and hence removes
all file/package conflicts from this package -- allowing to close this
bug
* keep the 'fsl' package as a meta package that depends on the latest
version of FSL and maintains the configuration setup of previous
package, to allow people to keep their existing setup and not have to
change a single thing if the only upgrade from fsl << 4.1.6-3
* introduce /usr/bin symlinks (via a wrapper) in the 'fsl-4.1' package
to address to configuration difficulty issue that was originally
intended to be improved with the previous attempt.
This time however, it will be version specific symlinks names that have
very little chance of conflicting -- ever. One of the previously
conflicting binaries 'immv' would now be 'fsl4.1-immv'.
Rational: version specific names allow multiple versions to coexists.
Symlinking to a wrapper script keep upstream script relying on a
specific environment setup intact (and all users relying on it
unaffected). Prefixing with 'fslMAJORVERSION-' instead of postfixing
with '-MAJORVERSION' has a reduced potential for confusion and future
conflicts. Think:
'slicer-4.1' (from FSL) and 'slicer3' (from slicer package)
vs
'fsl4.1-slicer' and 'slicer3'
If there are no fundamental objections to this approach, I'll upload
sometime over the next days.
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
