On Tue, Oct 10, 2000 at 10:03:59AM +0900, Stephen J. Turnbull wrote:
> >>>>> "Dan" == Dan Gohman <gohmandj_at_mrs.umn.edu> writes:
> 
>     Dan> I'm using the Debian source files as found on the coda ftp
>     Dan> site. These work quite well (even a debconf setup for
>     Dan> coda-client!). So far, I've noticed the following problems:
> 
> I've got a few problems, comments, and suggestions, too.
> 
> It would be nice if the debian subdirectory could be in the CVS tree.
> I would suggest a PMS subdirectory to configs, with "debian",
> "redhat", "SuSE" (and/or just one "RPM" for the RPM-using distros),
> "FreeBSD", etc subdirs.  Then add some code to bootstrap.sh to copy
> the data into the appropriate place.

Could be useful, although I'm still hoping for some packaging meta-file
from which the various files are created. They do have a lot in common,
and it is a pain having to update all the various places when a file is
added/removed. That was the reason why an important file like
/etc/coda/server.conf.ex was missing in the 5.3.8 release.

> I successfully built all packages using --srcdir.  I had to hack the
> debian/rules file in a minor way.  I plan to put together some patches
> (including the debian portion of the bootstrap.sh patch suggested
> above).  Remind me if you're interested, otherwise I probably won't
> get to it until I next have a "build Coda frenzy."

Hmm, I don't think I've needed that many hacks. At the moment I've got
updated stuff for 5.3.10, which even supports cross-compilation for
different architectures when dpkg-cross is installed.

> I noticed the debconf stuff being there, but it didn't seem to get
> triggered using dpkg -i ... is that only for dselect?

Maybe your dpkg is too old, or you indicated that only `urgent' queries
should be shown, it does get started here. dpkg-reconfigure coda-client
should do the trick.

> venus-setup still refers to /etc/conf.modules; on my system that file is
> ignored.  It should check for /etc/modules.conf and/or /etc/modutils.

venus-setup is really not needed anymore on Debian, because the
combination of post-install and debconf already should do everything
needed.

> vice-setup also did not request any user input; I don't know if it ran
> or not.

I haven't really done anything special for the server packages.

> What is the cachesize parameter at the bottom of venus.conf?

Stupid error in the postinstall/debconf configure script, it should have
been cacheblocks, so codaconfedit didn't replace cacheblocks with the
new value, but instead added cachesize at the end.

> The coda-client and coda-server packages are insufficiently careful
> about common files.  I inadvertantly installed coda-server on a
> notebook with an overfull /usr partition, so I removed it---which cost
> me my codaconfedit and coda-setup-ports scripts at least.  coda-common
> package, anyone?

Yeah, there are files shared by client and server, server and backup.
My current debian build comes up with,

coda-client
coda-update (rpc2portmap/updateclnt/updatesrv)
coda-backup
    depends coda-update
coda-server
    depends coda-update

coda-setup-ports is not needed on Debian, their /etc/services has always
been correct. So codaconfedit is the only shared one. I'm still trying
to figure out which package should own which files to make random
installation and removal of packages work well.

>     Dan> Having /usr/coda/tmp is suboptimal;
> 
> Agreed, this looks like an oversight.

Well, we've come a long way from having everything installed in
/usr/coda, but there are still some places that depend on the old ways.

I'll throw my current stuff on ftp.coda, look it over. And you are
right, it is probably a good idea to add it to CVS at some point.

Jan