[OpenAFS] 1.1.0 client on RH 7.1

[Sam Hartman]

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

    Jan> ...
    >>  Anyway, the presence of /usr/afsws/bin/blah and
    >> /usr/afsws/etc/blah links is merely to allow other scripts that
    >> haven't been updated yet to keep running even though they
    >> expect the AFS utils to be in those locations.  That's what the
    >> openafs-client-compat RPM is doing.
    >> 
    >> Rudy

    Jan> While I agree it is nice to fit the file location pattern of
    Jan> the platform, we should perhaps keep in mind all the other
    Jan> platforms AFS runs on. My AIX and Solaris machines have also
    Jan> AFS clients and need to use various AFS scripts. From this
    Jan> point of view, it is much easier to do so if locations are
    Jan> identical on all of them. There may be sites living in
    Jan> Linux-only world but often it's not so easy. Symbolic links
    Jan> to the necessary files seem like a nice solution. The links
    Jan> could point the other way though (from /usr/afsws/bin/blah to
    Jan> /bin/blah) for higher backwards compatibility.

Have a reasonable PATH that is set correctly for your arch, build your
own openafs, or depend on the compat packages.

    Jan> As for the server, I don't see any need for RPM, especially
    Jan> for upgrades (at least for us). bos install and the update
    Jan> server work quite nicely so it's really just a single machine
    Jan> for each platform that needs the manual update. Putting the
    Jan> server files in "system" place like /usr/sbin does not seem
    Jan> like a good solution for the upserver file distribution.  Am
    Jan> I missing something?

Yes.  You're missing all the sites that are considering installing AFS
for the first time and want something simple that fits their existing
model.

Certainly no one should force you to use the server rpms or debs or
AIX packages or whatever, but they are likely to be useful for many
sites.