[OpenAFS] 1.1.0 client on RH 7.1

[Sam Hartman]

>>>>> "Jan" == Jan Hrabe <hrabe@balrog.aecom.yu.edu> writes:

    Jan> What is so bad about the links pointing the way I suggested?

First, it requires me to install the compat package.  I want to see us
moving towards GNU Coding Standards style paths (respecting --prefix
etc) away from the broken build system we currently have.  I
understand the needs of existing sites require compatibility, but I
believe that for the vast majority of situations, symlinks from afsws
to the correct OS paths will do the trick.

For Debian I must have symlinks pointing out of afsws not into it.
Debian policy requires me to follow FHS for files I install.  afsws
is, putting it mildly, not compatible with FHS.  I interpret the
policy to mean that I can provide a script to create symlinks, but I
cannot actually have the symlinks in a package file.


    Jan> Building from source is what we are doing now and it looks
    Jan> like the way to go for our site. Someone mentioned building
    Jan> alternative packages with the traditional paths. Would it be
    Jan> feasible to distribute those as well on the openafs FTP
    Jan> server as aternatives?

    Jan> By all means. My point was that the upserver works, AFAIK,
    Jan> with the directories. If you put the server programs in
    Jan> /usr/sbin then the upserver would probably try to distribute
    Jan> that whole directory.  You could of course give up
    Jan> upclient/upserver in favour of RPM but that would be giving
    Jan> up functionality.

I think that having a deb or rpm or other package based update model
for all your software distribution provides more functionality than
upserver.  I don't really think upserver works that well for things
besides AFS.  But to each his own.  The AFS community will need to
support both because we have users using both styles of setup.