OpenAFS and Static Libraries

[Jack Neely]

On Sat, Mar 05, 2011 at 06:45:37PM -0800, Conrad Meyer wrote:
> On Fri, 4 Mar 2011 10:57:35 -0500
> Jack Neely <jjneely at ncsu.edu> wrote:
> > it looks like the proper thing to do is include these
> > static libraries in the -devel sub-package and have that
> > sub-package provide openafs-static.
> > 
> > Secondly, many more experienced AFS administrators prefer
> > the old Transarc style paths over the FHS paths that my
> > packages use.  I would like to create an openafs-transarc
> > sub-package that includes the symlinks that would enable
> > these non-standard paths.  (Specifically, /usr/afs
> > and /usr/vice.)
> > 
> > The first issue with the static libs really needs to
> > happen.  The second issue is just pure annoyance but will
> > make these packages more usable to certain folks.  I'd like
> > to do both.  Are there any comments or reason why I should
> > not?
> > 
> > Jack Neely
> 
> Both sound good to me (yes, the FHS is a nice ideal, but a
> compat package with "DEPRECATED" somewhere in the description
> is an ok crutch). And as Ralf has so helpfully pointed out,
> not even RH follows the FHS 100%.
> 
> -- 
> Conrad Meyer <cemeyer at cs.washington.edu>

So at this point I will definitely include the static libraries.
(Provided I can get them compiled with -fPIC so perl-AFS builds on
x86_64.  *grumble*)  Which means I might contribute perl-AFS in the
future.

For the Transarc paths, would folks like an openafs-compat package
rather than openafs-transarc?  (Transarc is the company Carnegie Mellon
spun off to commercially develop AFS before it was bought by IBM and
released as Open Source.)

Any news on the build system?

Jack

-- 
Jack Neely <jjneely at ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89