Bug#431724: Situation regarding mISDN

[Simon Richter]

Hi,

Lee Garrett wrote:

> Simon, if I get to write the HOWTO discussed in bug #431724, will you
> drop (comment out in the scripts) building module packages for the
> debian kernels?

Already done in my local tree.

> I guess for Lenny mISDN might have stabilized a little
> and it would be easier to maintain them then. I think its ten times more
> important to have up-to-date misdn libraries to work on than module
> packages. Do you have any other plans or ideas with this?

There will be a separate source package that builds these, but that 
depends on my "xcontrol" tool, so it probably will be another two weeks 
until I roll that out. Given that this has to go through NEW anyway, I 
don't think that matters much.

The difficult bit is going to be a sane init system.

Possible plan:

1. Upload 1.1.5-1 to unstable without any init system at all (so no 
change from earlier versions, should work as a drop-in replacement with 
whatever scripts users have built for themselves), and a DebConf note 
telling people to turn to experimental if they want to test the new init 
system (obviously, we keep that out of testing).

2. Upload 1.1.5-* to experimental with new udev-based init system. This 
will require a lot of scripting, as mISDN can coexist with I4L, and some 
people might want to run it in this way. Basically we need to get a list 
of all ISDN adapters (I guess the files in upstream's kernel package are 
going to be helpful there), and ask whether they want to use them with 
mISDN or I4L, then set up udev rules for that. Also we probably need to 
set up fake dependencies from the hardware driver modules to the l1, l2 
and l3 modules, I haven't checked that yet.

3. When that init system works, upload to unstable. Whether or not to 
remove the testing blocker at this point should be decided then.

4. Work with/against upstream to get a real init system working, which 
means teaching the kernel to defer loading the l1-3 drivers (this will, 
guess what, change the kernel<->userspace API/ABI again, but we can 
probably catch that in libmISDN). That was originally my plan for the 
CCCamp, but I was sick in bed during that time.

5. Upload to unstable, try to get into lenny.

6. ???

7. Profit

As mISDN is not in etch, there is no need for an upgrade path from 
anywhere (basically that was one of the reasons why I asked for it to be 
pulled from the release), which makes life a little easier.

I believe the sole user currently is chan_misdn. I think that during the 
time where the init system is not finished yet, this should still be 
built out-of-tree (well, my real thoughts for building everything in one 
big tree are not fit for writing); this will require asterisk to drop 
the misdn config file and a conflict from chan_misdn to any version that 
still ships it, but otherwise it should be pretty painless.

    Simon