Re: etc scripts

[Nathan Myers <ncm@best.com>]

David,

I'm cc'ing the Debian development list because some people there 
understand some of this stuff a lot better than I do, or can explain 
it better.
 
The subject was (roughly) how to get the dhcp client daemon started, 
and then the right mailer config file chosen, when a pcmcia network 
card is plugged in.  (This is aside from the issue of how to tell
when the network cable is plugged into the card; AFAIK we must 
assume it's plugged in already when the card is plugged in.)
(David Hinds is the PCMCIA god.)

David Hinds <dhinds@zen.stanford.edu> wrote:
> Nathan Myers <ncm@cantrip.org> wrote:
> > ...  creating a subdirectory /etc/pcmcia/network.d
> > and sourcing any files found in there, in sort-order, is more 
> > package-friendly.
> > 
> > In particular, it provides cross-distro package maintainers a place 
> > to put things.  Each distro can handle things its own way, but 
> > independent package maintainers who want to be portable to different
> > distros have a problem that you are uniquely equipped to solve.
> 
> Phew.  I guess I'm still not clear on what the solution would actually
> look like.  Back the problem out to the non-PCMCIA case: I don't see
> any good way the dhcpcd maintainer and MTA maintainers can coordinate
> configuration files so that this would work for a non-PCMCIA network
> device.  And if there isn't a good distribution-neutral way for two
> packages to interact for normal devices, solving the three-way
> PCMCIA-dhcpcd-MTA interaction seems moot.

It's a problem that needs to be solved, though, no matter how hard
it may be.  People *do* need to be able to plug into a network 
without manually fooling around with all their config files, and 
unplug without fooling around with the same ones again.

I should explain my original proposal better.  First, code:
In /etc/pcmcia/network, add:

  for i in /etc/pcmcia/network.d/S*; do 
    if [ -f "$i" ] && [ -x "$i" ]; then 
      . $i
    fi
  done

This replaces all the "if is_true" stuff in /etc/pcmcia/network.
The contents of those "if" blocks will become scripts in the 
directory network.d.

There are many MTAs, DCHP clients, and BOOTP setups, but just one 
PCMCIA subsystem.  No MTA should know about DHCP or even about PCMCIA.  
DHCP shouldn't know about MTA config files.   There's no way for one 
package to know about them all, but PCMCIA being central provides a 
good place to coordinate them.  If it can't know them all, it 
shouldn't know any of them, if that's possible.

Integration is always work, but with the right apparatus in place
it can be localized where it belongs.

The Debian solution is to create a separate package that does know
how to integrate other packages, so (e.g.) the "dhcp-pcmcia" package
would know how to get the dhcp client daemon started, and the
"exim-pcmcia" file knows how to get the right config file selected
for the network neighborhood discovered by the dhcp client.  It's
the job of the release manager (a person) to make sure the packages
name the scripts they place in the directory correctly, to be called
in the right order.

The result is that the PCMCIA package doesn't know *anything* about 
that other stuff, and your scripts get a lot smaller, but at the same 
time more powerful because they can now enable a solution to the hard 
integration problem.  It gets more distribution-neutral because you 
have eliminated a lot of apparatus that would otherwise have conflicted 
with how a distribution wants to do it.  It gets easier to maintain
because you can forget all details about DHCP and BOOTP.

Nathan Myers
ncm@cantrip.org

(As a postscript, I don't know how Debian actually handles PCMCIA 
now, because its pcmcia-cs packages have always been so far behind
your releases that I never had cause to try them.)