Hello,

pity to hear that people are giving up with Coda.

The reason *might* be in trying to hide the complexity and "make it easy",
while creating excessive complexity for that purpose?

My own experience is that for such a complicated service as
coda server or client, it is very hard to make a package surviving
installation in very different circumstances. It is even worse when
trying to upgrade.

It costs a lot of time to make a reasonably "bulletproof" package for one
system/distribution. Multiply with distributions versions and
variations...

I would think Jan could provide the functionality but rather someone else
should maintain packaging. It is a big work and it demands a deep
knowledge of both the product and the system and distribution policies and
tools. Not that Jan lacks that knowledge, he lacks the time.

> I got the coda RPMs, but decided it was just not worth the trouble
> to try to deal with all the version incompatibilities.

Exactly.

> Surely it wouldn't be that difficult to create contemporary RPMs?

I am not sure how good RPMs can be done.

I have recently looked at commercial DCE for Linux packaging (RedHat rpms)
and well, for us it is unusable out of the box, we have to run homegrown
scripts to configure it. The reason - too many assumptions that had to be
made to make the installation "easy". Instead, they made it impossible.

I think Coda is in almost comparable range of complexity.

I do not like the fact that Coda configuration scripts try to contain a
lot of hooks and heuristics about different environments they have to be
functional in. It does not belong to the functionality and it makes it
harder to understand Coda. Then when it breaks, it is treated as "Coda
fault" :( [Even a well configured] computer system may still break scripts
that contain too many assumptions and try to suit any of 50 "known"
environments. In the real world there are more anyway.

I think simple *system-independent* configuration interface to the coda
tools complemented by *documentation* what the things mean
would make the install success ratio higher than trying to wrap the things
down (into some "artificial intelligence" implemented in /bin/sh or perl).

Let's state explicitely:
 - these daemons have to be started in this order
   and taken down in that order
   (or - this script has to be run to start, that one - to stop, but do
   not build knowledge about the system(s) into these scripts)

 - these binaries are using following config files and libraries
   (exact list)

 - these choices (pointer into configfiles) influence the following...

Then let the local sysadm arrange the placement, startup and shutdown, he
   knows the concepts, what processes and libraries are...
   or am I too optimistic? :-)
   ok, let "distribution packager" arrange that, anyway it does not
   belong to Coda itself.

The above might work better that scripts that make it right in 90%
cases but contain so excessive logic that it is hard to understand and
fix them.

Best regards
--
Ivan
a happy Coda admin
(still not using replication)