[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: