Re: NCPFS seems broken on 2.1 kernels...
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
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: