this discussion was recently mirrored by smbfs on debian-devel result, IIRC, was to have scripts that dynamically branch on kernel version
> [...] > > Also, packages ncpfs and ncpfsx have lots of > binaries, not just the ncpmount and ncpumount binaries, so this will add > more complexity to these stub scripts. > > I didn't realize how many there were. However, I think this can still > work. Try this: > > All the 2.0.x versions get installed as <name>-2.0.x > All the 2.1.x versions get installed as <name>-2.1.x > The generic stubs are installed as <name>, which are all > symlinked to `nwstub' (or whatever name). `nwstub' is the following > script, or an adaptation of the same idea: please, if somebody multiboots between different kernels this has a fair change of breaking, as also happens on kernel upgrades > #! /bin/sh > echo $0-`uname -r | cut -b 1-3`.x $* > > If someone comes with a better solution than having two packages I am > willing to consider implementing it. > > Some people suggested that I use alternatives. That looks like a good idea > for packages with a small number of binaries like packages smbfs and smbfsx > but for packages like ncpfs and ncpfsx the number of alternatives that > would need to be set up is quite large. So, in this case, I preferred to > have ncpfs and ncpfsx conflict with each other so only one can be installed > at any time. > > I agree that alternatives would be clumsy for this. If the sysadmin > wanted to switch, he'd have to relink an unreasonable number of files. same drawback as plain symlinks t.aa -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
