Re: NCPFS seems broken on 2.1 kernels...

[Ben Pfaff <pfaffben@pilot.msu.edu>]

   At 09:15 AM 2/15/98 -0500, Ben Pfaff wrote:

   >   OK guys, I finally managed to make ncpfs-2.1.1 compile and work under
   >   libc6. I have just released a new package called ncpfsx. Use this
   >   package if you want to play around with ncpfs and kernels > 2.1.29.
   >   For older kernels use package ncpfs.
   >
   >Would it be more convenient to merge the ncpfs and ncpfsx packages and
   >include stub scripts that check the kernel version and call the
   >appropriate binary based on whether it's 2.0.x or 2.1.x?  Is this
   >possible?

   I have thought about this but have been unable to find a better solution.
   The problem is that upstream ncpfs-2.0.x and ncpfs-2.1.x are different
   packages and I don't know how to create a binary package (a .deb) from two
   different source packages.

I have run into this problem myself a couple of times.  What you have
to do is put both source packages under a directory and make that
directory the source package.  It's not lovely, but it works.  The
Debian source package mechanism isn't intended to fit all possible
packaging methods; witness my troffcvt and checker packages, which
both have 8 or 10 different tarballs needed for compiling.
			      
			      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:

#! /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.


--
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 .