Hi Stephen,

Wow, that's a lot and useful feedback, I'll quickly go through some of
the things, and probably catch up with the rest tomorrow.

On Mon, Apr 17, 2000 at 03:02:28PM +0900, Stephen J. Turnbull wrote:
> 1. `make maintainer-clean' is happy, happy in ./lwp, ./rvm, and
> ./rpc2, leaving no cruft (although it does delete two INSTALL files
> which are in CVS, not sure which).  The closest thing for ./coda,
> `make distclean', leaves about a dozen pieces of cruft according to
> CVS.
> 
> Debian likes to do `make distclean', or even more stringent cleaning,
> after building source packages.  Me too.  Just compulsive, I
> guess....  I can supply patches if you like.

Ok, the INSTALL files that got lost is because they only got added later
on, forgot to remove them from the list of files to clean up. The main
tree is not `automake' based and the whole make environment is a bit
messy, that's why it is leaving the debris around.

> 2. I probably will make Debian packages for my personal use (so I can
> move the coda stuff out of /usr/local into /usr).  I am unwilling to
> commit to being a Debian maintainer (this will be the first serious

I've already got lwp, rpc2 and rvm packaged up, I'll put them on the ftp
site tomorrow. I wanted to base the coda package on the one that Anders
Hammarquist had, but haven't had time to dig into that one yet.

> 4. Also, the space in /usr is pretty tight for me; this got me into
...
> I would strongly prefer that all log files, RVM, RVM transaction logs,
> Venus cache files, etc live under /var.  This can probably be easily
> configured with autoconf options, and done automatically in Debian if
> you prefer the /usr setup that is now the default.  Please note that
> the File Hierarchy Standard that all Linux distributions claim
> conformance to may mandate the relocation of these things to /var.
> (This kind of policy issue would have to be settled before a proper
> Debian packaging could be done.)

Check out /etc/coda/venus.conf, you'll be surprised how easy it is to
move those things around.

> 5. Check out this listing:
...
>     drwxr-xr-x    2 500      nogroup      2048 Apr 14 19:06 Projects
>     drwxrwxrwx    2 root     nogroup      2048 Apr 14 19:07 Research
>     drwxrwxrwx    2 root     nogroup      2048 Apr 14 19:06 Teach
> 
> `Projects' is a directory made with mkdir by the Coda administrator,
> `Research' and `Teach' are volume mount points.  It's not obvious from

The Research and Teach mountpoints are actually symlinks, that is why
they show up so weird. Don't worry, Coda almost completely ignores
user/group and modeflags, access permission is based on ACLs (chmod
444 Projects, and you'll still be able to see the contents). We simply
aren't updating this information in the directories as it is user
specific and it is difficult to let the kernel have multiple views on
the same directory data.

> 6. BTW, if there was a coda-doc module in the CVS tree I would be more
> than happy to putter around in the HOWTO and man pages, patching what

`cvs co doc', but it is a bit of a mess. We're moving from linuxdoc to
DocBook and are pretty far on getting an updated "Coda Users and System
administrators manual", without the current outdated information, more
concise and merged with the information from the howto.

> don't grok ;-)  (Is there an official place to send patches?)

coda_at_cs.cmu.edu, or jaharkes_at_cs.cmu.edu will hit the spot.

> Weird.  Oh well....  (Of course df doesn't really work, it tells me
> "9000000" which has nothing to do with any of my Coda capacities.  But

Output of df depends on kernel version, the cache-size information was
added later on in the 2.2 kernels. If venus doesn't respond, df hangs,
if venus is dead it fakes some output like AFS does.

> 10. Ah, the compile and install on the P5-120 is now finished.  Oh,
> yeah; at least on my Debian systems, /etc/conf.modules is completely
> ignored, except for a warning, in favor of /etc/modules.conf.

Yes, there are probably more distribution dependent differences,
installing the init scripts for instance (using update-rc.d).

> 11. Doing a CVS checkout of XEmacs into /coda/Projects/XEmacs.
> chugga-chugga, chugga-chugga, ... slow, slow.  But then, everything in
> my testbed Coda installation currently lives in one partition of one
> ATAPI drive, one gets what one pays for ;-)

We are definitely slow on directory operations, create/mkdir/unlink,
write-disconnected mode helps as we don't have to talk to the servers to
perform each operation.

Jan