On Thu, Sep 2, 2010 at 13:02:33 -0400, Michael Hanke wrote: > 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. > Thanks, this all sounds good to me.
Cheers, Julien
signature.asc
Description: Digital signature
