State of the "dunc" package [long]
I recently walked a friend through installing dunc-2.1 on a
slackware box (from the debian package). The first thing we both
noticed was how easy it is to install debian software on
non-debian systems[1]. The second thing we noticed was the the
version of dialog (although the upstream version was in sync with
the debian dependency's) was incompatable -- it core dumped every
time we ran it. So we got the debian dialog package and
installed it and all was fine. Then we noticed (to my
embarassment) that the program never created the BASEDIR
directory and failed to run. We also noticed that the "dppp
--help" was useless as the screen cleared before you could read
the text.
The good news was the we manually created the BASEDIR driectory
and dunc ran very well. He hit enter a few times, typed in his
username and password, hit enter a few more times and was up and
running. His ISP provides PAP and CHAT style connections and
both methods tested fine. The RCFILE needed some cleaning up
after the BASEDIR was finally made though. The problem is that
the dunc script checks for duplicate connection definition files
in $BASEDIR, but assumes $BASEDIR exists. If it doesn't, then
$RCFILE will get updated with the connection information, but the
write to $BASEDIR/<connection name>.ctn will fail. The next time
you try to set up a connection, the name will be valid in $RCFILE
but not in $BASEDIR, thus allowing you to recreate the same
connection (i.e. use the same name.) This lead to the first
(empty) case block of the connection name in $RCFILE being
initialized and causing more confusion during future program
runs. The only solution was to edit $RCFILE.
The RCFILE was structured to allow one to recover lost
connections, or duplicate them, from the RCFILE. This feature
was not implemented, however. I haven't been able to come up
with a way to easily integrate this behavior into the script as
is. but I read Sven's post about rewriting dinstall in C, and I
think it would much easier to deal with a lot of the stuff dunc
attempts to do in C. Unless there are any serious objections,
the next version of dunc will deal with the above situation
better, and it will be modeled after dinstall in C(+giggle?).
There are two questions I have:
1) what would be the best way to deal with broken $RCFILEs as a
result of the previously mentioned scenerio?
2) Is there anyone knowledgeable in PPP who could stay subscribed
to the PPP list(s) and help out with the dunc implementation?
I'm willing to remain the maintainer, but I think the package
could use some help, especially moving forward with the latest
PPP. I'd also be willing to turn the package over to someone who
could do a better job with it. I'm unable to subscribe to the
lists and have little time to spend on development. (one of the
other things we noticed was the there is no way in dunc to
specify a longer timeout. The ISP defaulted to PAP, and must
have had a list of protocols to try -- chat being last. Sometime
it was OK, but sometimes it wasn't).
[1] This is actually a very good selling point for the package
format. Perhaps debian-publicity should start marketing the
format based on its strength (not comparing it to any other
format, of course), and ease of use. That is, assuming we're not
dumping it for a commercial format ;)
Thanks
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: