>>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

    >> Note that coda-client.postinst "helpfully" overwrites an
    >> existing setting for realm every time.  Stifle that while
    >> you're fixing the default, please.

    Jan> It uses the setting you (probably) specified with debconf
    Jan> when venus was installed.

Nope, I have _never_ been asked.  Anyway, it shouldn't have a hard-
coded default, it should default to whatever the rootserver is set to.
That means that if you're not setting rootserver by debconf, you
shouldn't set authserver or realm by debconf, either.  That's what I
found most surprising: rootservers is replicated (I get a new copy
with the old one commented out every time) while realm keeps getting
reset without any notification from debconf.  So debconf does know my
rootserver, but was using a hard-coded default for realm.

I treat debconf as a hostile imperialist agent.  "ALL CONFIGS YOURS
NOW CONFIGS OURS ARE."  If it gives me the option (eg, with
XF86Config-4), I always Just Say No to debconf.  (I wish it would let
me do so with Apache, whose scripts have been broken in one way or
another, at least on my system, for over six months now.)

    Jan> At the moment the cache size and default authentication realm
    Jan> are both managed by debconf. Should such things not be
    Jan> managed at all? It would make the various platforms more
    Jan> similar in the way of configuration.

What I think would be good for Coda exposure to new users would be a
single question:

    I can set up the connection to CMU's Coda testserver.  This will
    allow you to play in CMU's anonymous Coda area, and give Coda
    access to the FTP download area so you can use cp(1) instead of
    ftp(1) to access coda source files and documentation.  This
    configuration is almost surely not what you will want if you plan
    to set up your own Coda cell.

    If you just want to see how Coda works, play with ACLs and the
    like, say "yes" to the following question. (You can alway
    reconfigure with "venus-setup" later, which will change the
    defaults and reinitialize the file system cache.)  If you are
    already planning to set up a Coda cell, say "No", read the
    documentation, and use "venus-setup" when you are ready.

    Do you want me to set up your client as part of CMU's testserver
    cell?

            [Yes]                [No]                [Cancel]

If you want to do the extra work, on "No" you could have it ask "Do
you know all configuration parameters for your Coda cell?" and if yes,
run venus-setup or have debconf ask all the specific questions.  If
you use debconf, then substitute "dpkg-reconfigure" for "venus-setup".
(BTW, in case you like this approach, I place the above template in
the public domain, use as much or as little of my words as convenient.)

    Jan> Looking at what we do for client configuration, in most cases
    Jan> there is really little need to change any of the default
    Jan> options except for maybe cachesize. venus-setup mostly just
    Jan> checks a couple of things that tend to be missing on some
    Jan> systems (/dev/cfs0 character device, /etc/services entries).

I guess that's true.  When I started with Coda, RVM partitions seemed
to be the recommended configuration.  Now it's just a matter of
checking that there's enough disk space for the LOG and DATA files,
isn't it?  After that, you set the various root option (rootservers,
authservers, and realm).

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.