Basic question: how do I handle building external kernel modulesfrom different packages that depend on one another?
(As for the workaround of getting either into mainline: tried, and doesn't work. At least not now) I have a module called "Mainmod" in package "mainmod-source", and it depends on code from module "Provider" from package "provider-source". If Provider is not available when Mainmod is built, there will be no proper dependency between them. e.g: 'modprobe mainmod' will not pull Provider and if Provider happens not to be loaded at the time, the load of mainmod will fail. This post regards post-Lenny issues. So what do we have here: Long ago (at around 2000) Jim Dixon developed a new T1/E1 card. He has considered his card revolutionary[0] and thus named the card Tormenta and the drivers (for FreeBSD at the time) were named Zapata Telephony, after Emiliano Zapata. At around that time a certain company (called "Zaptel Corporation) thought "zaptel" is a nice name for calling cards. The site of that company is http://zaptel.com/ . Soon those drivers were ported to Linux as well. Mainly due to the help of Mark Spencer who had a voip/telephony software called Asterisk for which he wanted a decent hardware interface. Since then Mark Specer has changed the name of his company to Digium, and they are now the primary developers of both Zaptel and Asterisk. The policy of the company is to dual-license code and hence contribution to the project has sometimes met with difficulties. So not only is Zaptel an external kernel module, but there are also some card drivers that use it that are not included in the main distribution. Thus the Debian package includes drivers from the "bristuff" distribution, vzaphfc, a Zaptel driver for a Voicetronix card, and others. There is a RFP for the Sangoma drivers (http://bugs.debian.org/486160 ), and noone has yet asked for the Rhino drivers, which are also actively maintained. Thus we so far Thus we avoided the dependency problem by putting everything in the same packaging. This has also made the Debian package a partial upstream. Zaptel has also included a line echo canceller for quite some time. But it wasn't well-designed and tested and never really worked properly. Some cards have a hardware-based echo cancellers on-board. There are two proprietary software-based echo cancellers (one from Octasic, and the other is HPEC, that is distributed by Digium. David Rowe has set out to create a better echo canceller. The result is OSLEC: Open Source Line Echo Canceller: http://www.rowetel.com/ucasterisk/oslec.html . It is mostly used by zaptel, but also by mISDN . For both it requires some patching. Upstream includes it as a separate source tarball (but rarely releases tarballs. It is best to use latest SVN, normally). Oslec actually works, which is why I wanted it in Debian. To avoid any issues, I have chosen to include it as part of the package Zaptel. This also required some repackaging but avoided the dependency mess. We also don't really include mISDN (mISDN 1.1.x seems to be considered too buggy, and mISDN 1.2 will hopefully make it to mainline kernel). So Zaptel was the only user for us. At around 2005 the Zaptel Corporation got annoyed by people looking for "Zaptel[.com] [calling] card" and end up finding "Zap[ate ]tel[phony] [PCI] cards". Sadly, they were the ones who registered the trademark and thus once again a software of Mark Spencer had to be renamed. The new name chosen was "DAHDI" (Digium Asterisk Hardware Device Interface[1]). While not all people like the name and what it stands for, the rename took place. With the rename, some substantial changes were made and the kernel ABI was explicitly broken (a different ioctl type, different /proc and /dev directories). Lenny has Zaptel 1.4.21 . Asterisk versions in the 1.4 branch as of the upcoming 1.4.22 will build with either Zaptel or Dahdi. The upcoming 1.6.0 will only use DAHDI. Which means that we'll eventually need to include DAHDI, though this is a post-Lenny task. I have started packaging it (at svn://svn.debian.org/pkg-voip/dahdi-linux/trunk ). If I want to use the same method for including oslec, I'll have two versions of OSLEC in the archive, which is probably not such a grand idea. Thus I need to put OSLEC in a separate package. So in short: we now have just one "zaptel" modules package. But it seems that we need to have: oslec zaptel: uses oslec dahdi: uses oslec wanpipe: uses either zaptel or dahdi And maybe some other drivers in the same position as wanpipe. How will this get built? Should a built provider-modules-$KVERS package include a snippet of Module.symvers that will be used when building mainmod-modules-$KVERS ? [0] The article was originally on asteriskdocs.org and on zapatatelephony.org . Right now I can only find it in the archives: http://web.archive.org/web/20050121120343/http://www.asteriskdocs.org/modules/tinycontent/index.php?id=10 http://zapatatelephony.org/ itself is a bit of archeology. And in case you wonder: yes, those Zaptel cards do sell well even in Mexico [1] DAHDI is also the name of a board game from India and maybe of a town/city in Iran. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il | | a Mutt's [EMAIL PROTECTED] | | best ICQ# 16849754 | | friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]