module-assistant support for zaptel

[Tzafrir Cohen]

On Sat, Mar 26, 2005 at 02:08:04AM +0100, Jose Carlos Garcia Sogo wrote:
> 
>  Hi again!
> 
>  Module-assistant support is completed by the time you read this mail.
> For now, we are shipping a overrides file for module-assistant, but a
> bug has also been filled in that package to cope with this little
> problem. Thus, I have uploaded all this to svn.

Looking over the diff, here's something:

- This package contains the source code for zaptel, a kernel module providing
- the Zapata telephony API, and device drivers for various telephony hardware,
- including the Wildcard series of interface cards (X100P, T400P, E400P, S100P,
- S100U).
+ This package contains the source code for zaptel kernel module providing
+ device drivers for various telephony hardware, including the Wildcard 
+ series of interface cards (X100P, T400P, E400P, S100P, S100U).

So while we're at fixing the descriptions, what extra hardware is 
supported by zaphfc?

Apart from that, I moved all the file copying I could to after copying
the files from tmp/ to the packages directories. This allows the use of
dh_installexamples and dh_installdocs and simple dh_install without
explicit cp and install. I have no idea who'd like to override those
commands later.

The name 'zaptel' appears too many times in that package. I tried to
replace it with my own var called SRCPKG to make it easier to 
copy&paste copde from this package to another one. Is there such
existing debian/rules var?

If the target foo-stamp ends with 'touch foo-stamp' it better be
replaced with 'touch $@'. This way it won't have to be edited when the
target name changes.

I also used make text functions instead of a call to sed through shell
to calculate KVER . However if you ever define a variable using 
$(shell command) use:

  var := $(shell command)

Rather than:

  var = $(shell command)

Otherwise the shell command will be re-expanded every time you use this
variable.

torisa.h is created as a symlink to a directory that is not guaranteed
to be generated until m-a has been invodes. Nor is it guaranteed to be
of the right version, because m-a is run on-top of dpkg/apt and not by
dpkg/apt.

After playing with m-a a bit, I still don't see it saving me work with
automated builds. It requires quite a lot of initial setup, and most of
it appears to be the job of root. 

In addition, packaging the files in an internat tgz bypasses any sanity 
check lintian and others would do to them.

I've played with it all day long and it seems very unsuitable for
non-root builds. If it requires that the code module is compressed to a
rather than kept in its own directory than it really does harm. If not,
I have no problem with it and it might actually turn out useful one day.

> 
>  I have also changed and improved package descriptions (please review
> and comment) and I have added a README.Debian file telling about how to
> compile modules and use them with udev.

Hmmm... Something the user has to do. Is there any way to do it for the
user?

For instance, quoting from README.Debian:

| If you cannot access the zap/ctl device, check which user asterisk is 
| running as and add these permissions to your permissions file
| (ie /etc/udev/permissions.d/50-udev.permissions):
| # zaptel devices -- if you want to run asterisk as a different user
| # (asterisk in this case, subtitute it for the appropiate one)
| zap/*:asterisk:asterisk:660

So shouldn't the asterisk package include a file
/etc/udev/permissions.d/60-asterisk-udev.permissions which reads:

  zap/*:asterisk:asterisk:660

In thoe worst case the use will have to unload and load the zaptel
modules.

In addition, hotplug does a good job at detecting the PCI cards. I
wouldn't think of automating the scan after installing zaptel. However
telling the user how to do that would help. 

Anything better than /etc/init.d/hotplug restart ?

Another common case to handle is installation of kernel 2.4 without udev
and without devfs (the default of sarge). My current hack for them is to
create the device files at asterisk install time if no udev/devfs is
detected.

This won't help in a case where someone installed asterisk with kernel 
2.6/udev but later runs with kernel 2.4/no-udev. But it still handles
the common case and does practically no harm.

> 
>  Last, I have a comment to make on device ownership. When we create them
> by hand, when udev or devfs is not being used, we set the ownership for
> them as root.dialout. At the same time, asterisk is being runned as
> asterisk.asterisk, and user asterisk is only added to audio group. Here
> there is a lack of coordination. Or we think that zaptel is going to be
> used only by asterisk, and we make devices as root.asterisk (which has
> the problem of failing if asterisk is not installed), or we add asterisk
> to dialout group, which has the problem of giving with thas asterisk
> power to lauch modem calls (using ppp, for example)

Moreover. The x100p is practically a modem with the PCI ID of such.
Other TDM cards have the PCI IDs of some ISDN cards. Giving permissions
to dialout on them may actually cause confusion: it has the pci ids
of a modem, and the permissions of a modem, so it must be a modem :-) .

However asterisk is not the only user of zaptel. What about yate? I
don't want the config files of Asterisk to mess with the installation of
yate and vice-versa.

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen@xorcom.com  http://www.xorcom.com