Hi Jan,

> Hi Anders,
> 
> Well, I'm the Debian advocate in the coda-group. However, I haven't been
> able to persuade anyone into using Debian. Mainly because all our 55+
> machines are a maintainers headache already (Imagine a mix of i386 with
> RedHat, FreeBSD, NetBSD (both with stable and unstable kernels), 2 alpha's,
> a couple of Sparcstations, and 1 guy to make sure we have `bleeding edge'
> software and all security holes are plugged.
> 
> (I know, with a debian installation we get all this easily, that's exactly
> what I've been saying, but who listens????)

Well, you know how it is, just because something works better... ;-)

> Now to the serious points,
> 
> I've looked at the packages (4.6.1-1), here a a couple of notes:
> 
> The source-diff doesn't seem to include anything else but CVS-related
> differences. (Which is another religous war I'm fighting here, we should
> not have CVS crap in out tarballs, but those same tarballs are used to
> install on our own (new) systems, so that changes can easily be committed)

There *should* be other changes in there (and, looking at my copy of the diff, 
there are). The changes I did, apart from adding the debian stuff, was to 
change a bunch of /bin/csh into /usr/bin/tcsh. There is a lot of CVS diffs 
though (I like to keep my stuff in CVS for obvious reasons. I'll see if I can 
have the diff ignore the CVS changes - they really aren't all that relevant.)

Incidentally, is anyone considering/working on turning the tcsh scripts into 
sh scripts? If not, I'll have a look at it.

> I saw you didn't have man-pages in coda-doc or coda-client/server, I
> believe that in the redhat packages they are present in the coda-doc.rpm's.
> Yes, we should release tarball's for the documentation too.

They are in separate packages (coda-manpages*), made from the BSD manpages 
tarball. (They didn't get installed into the archives at the same time as the 
rest of the coda packages for some reason.) Now if only dpkg would support 
multiple upstream tarballs I could put them into the coda-client/server 
packages and still use pristine upstream sources...

> I really like the pre/post installation scripts. That's something I never
> got to in my own packaging (Yes, I've done some debian packages as of
> coda-4.1.3, see http://www.cwi.nl/~jaharkes/coda/, I never released them
> since both the packaging and coda were not ready for prime-time)

Thank you. I did spend some time to get them working nicely, it's nice to know 
it was appreciated :-)

> I noticed how you got around the stupid hardcoded path's to /usr/coda,
> does your setup actually work (have to try that), especially with the
> DATA and LOG rvm files? We are planning to move things to more standard
> places (/var/cache/coda, etc.)

Unfortunately, it doesn't seem to be working for the LOG rvm file (the link 
keeps going away...) It works for the other files though.

> The server package has got something strange, the directories /backup, /db,
> /srv, /vol, /bin, and /auth2 should be /vice/backup, etc.

It seems I botched something when I was finishing it up (it was late). I'll 
take care of it for the next upload.

> As a quick side-note, we've gotten the official IANA assigned port-numbers,
> and are planning to release an severly incompatible version, all clients and
> servers older than 4.6.4 (or 5) will not in any way be able to communicate
> with the ones in the new release. As the /etc/services in debian is located in
> another package, it might be useful to `synchronize' this update (or making
> sure that netbase is up-to-date before coda-* leaves project/experimental.

OK, I'll solve this in one way or another (per policy I can't touch 
/etc/services - but then it's still in experimental so I don't have to be 
entirely policy compliant). Any time-frame on when you will be releasing with 
the IANA port-numbers? (I just hope the netbase maintainer doesn't go changing 
/etc/services before I get the new packages out or I suspect things can break 
in strange and mysterious ways.)

Regards,
/Anders