module-assistant support for zaptel

Tzafrir Cohen tzafrir.cohen@xorcom.com
Fri, 01 Apr 2005 22:01:30 +0300


On Fri, Apr 01, 2005 at 08:03:35PM +0200, Jose Carlos Garcia Sogo wro=
te:
> El vie, 01-04-2005 a las 18:22 +0300, Tzafrir Cohen escribi=F3:
> [...]
> >=20
> > OK. Finally got it working. This was done by replacing the bogus
> > /usr/share/modass/packages/zaptel-source with a "standard" one. I=
 didn't
> > put any "override" as I don't believe we need to fix in zaptel-so=
urce a
> > bug of module-assistant. For now I'd recommend the user to manual=
ly:
> >=20
> >   rm /usr/share/modass/packages/zaptel-source=20
> >   ln -s default.sh /usr/share/modass/packages/zaptel-source=20
>=20
>  Gah! Sad to hear this. I think that for some reason you're not usi=
ng
> latest zaptel from SVN. During some days a zaptel-source.modass fil=
e
> existed in SVN which was installed as an override for m-a. I filled=
 a
> bug which was fixed the other day, so I changed back to don't ship =
that
> overrides file and depend on m-a >=3D 0.8.1
>=20
> >=20
> > I don't see why such file should exist in modass if the source fo=
r
> > zaptel is not available in the first place. It should be provided=
 by
> > zaptel-source and not exist if zaptel-source is not installed. At=
 the
> > moment ModAss reports of many shource packages I have "available"=
 when I
> > actually have almost none of them.
>=20
>  They are there because you can select them and let m-a install sou=
rce
> package if needed. That is the way that m-a a-i module works. For t=
hat
> it needs to have first a file telling m-a which packages it does ne=
ed to
> install (using apt).

Let's do a little test:

  for file in `ls /usr/share/modass/packages/`; do apt-cache show $fi=
le &>/dev/null || echo $file; done

This gives "source packages" that are supposed to be avilable and yet
apt does not know them. On my system:

  acx100-source
=09at76c503a-source
=09bcm5700-source
=09cpcieject-source
=09cryptoapi-core-source
=09cryptoloop-source
=09e100-source
=09em8300-source
=09ftpfs-src
=09ipw2100-source
=09ipw2200-source
=09nvidia-kernel-source
=09openswan-modules-source
=09qce-source
=09qla2x00-source
=09sl-modem-source
=09syscalltrack-source
=09unicorn-source
=09xdslusb-source
=09xlibmesa-drm-src

I didn't ceck all of them, but the three I've checked are from
contrib/non-free and thus are not available for my system. Others may=
 be
plain obsolete.

OTOH, the list of packages that depend on module-assistant is rather
short:

$ apt-cache rdepends module-assistant
module-assistant
Reverse Depends:
  zaptel-source
  translucency-source
  tidev-modules-source
  shfs-source
  ppscsi-source
  ndiswrapper-source
  lufs-source
  loop-aes-source
  loop-aes-ciphers-source
  lm-sensors-source
  i2c-source
  hostap-source
  gpib-modules-source
  fwatch-modules-src
  fuse-source
  eagle-usb-modules-source
  drbd0.7-module-source
  cloop-src
  cdfs-src
  bcm4400-source

I see no reason why m-a should magically identify and install source
packages that were not built for use with it.

So module-assistant and my apt database are out-of-sync. Why should
module-assistant keep its own database separate from apt?

Anywaym that's my opinion regarding a package that is not part of
pkg-voip.

>=20
> >=20
> > Anyway, my rules file is attached. It has very few rapid-specific=
 parts,
> > but I believe that both those changes should come into Debian:
> >=20
> > 1. There should not be a default /etc/zaptel.conf . It is documen=
ted in
> > the example. If you want to satisfy ztcfg, touch /etc/zaptel.conf=
 on
> > postinst it there is no such file. However there is no point in b=
eing
> > asked ot upgrade it by dpkg when upgrading the package.
>=20
>   I am not sure about this. But taking a look at the config file, a=
nd
> how criptic it is, I don't think we loose a lot by putting it
> in /usr/share/doc and telling in README.Debian to copy it over to /=
etc
> if desired... But I would like to hear more comments.
>=20
>=20
> > 2. genzaptelconf is not yet in Debin. Do I need to=20
> > file a bug to have it included?
>=20
>   Does this need to be in a separate source package, or can we incl=
ude
> it with zaptel?

considering it is a simple shell script, I don't believe it warants i=
ts
own package. genzaptelconf may also be used to generate a default
zaptel.conf for the system, assuming that all kernel modules have bee=
n
loaded.

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