[OpenAFS-devel] open issues for an openafs 1.8 branch

[Benjamin Kaduk]

Hi all,

In today's release-team meeting we discussed many items relating to an
imminent 1.8 release branch, but there are several for which we'd like
input from the broader developer community.  We're aiming to have all the
decisions made and patches merged by Wednesday 10/8 (in two weeks' time).

(The numbers below do not
bear any relation to the numbers or letters in the jabber logs.)

(1) Should we install .la files for shared libraries?

We are now using libtool to build things.  Some people like to install the
.la file for external consumers to use.  Some people don't.  Debian falls
in the latter category, which leans me toward it as well.

I am rather inclined to say that our use of libtool should be considered
an internal implementation detail which does not get leaked to the outside
world, but I don't really have any justification for feeling that way.

(2) SONAME bumps for libtoolized shared libraries.

We have a handful of shared libraries that we install (most notably,
libafsrpc, libafsauthent, and libkopenafs).  The plan is for them to be
built using libtool for the 1.8 branch (gerrit 11461, 11462, and 11484).
As far as I know, the contents of these libraries hasn't notably changed
across the build system transition.  But can I be sure?  There are a lot
of variables, and what if we miss something?  It seems prudent to bump
the library SONAME "just in case", since the consequences of not doing
so are large, we've made a major change in how they are built, and this
is a major release boundary.

Does that seem reasonable?  Or should we try to keep consistency with the
old numbers?

(3) Dropping the Netscape plugin and related bits from our tree

If you go to src/libuafs and run 'make webinstall', we try to build a
thing.  (We don't try to build it otherwise.)  I'm not even entirely sure
what this thing is, or its relationship to the bits in src/afsweb, but
they are talking about "Netscape plugin" and "apache 1.3.1", and these
things are quite old.  It's unclear that they even build at the moment --
I didn't try.

Jeffrey notes that JPL was using "the web stuff" as of 2005.  On the other
hand, Netscape stopped being a thing in 2008.

Anyway, it seems likely that these things do not belong in the openafs
source tree.  If some site(s) require that functionality, the code should
still be usable as an external module that links against the libraries
we supply.

So, do we have consensus in favor of removing these bits from the openafs
tree?

(4) changing fileserver tuning

The fileserver lets you pass arguments like -S and -L for "small" and
"large" setups.  But ... the "large" one is actually quite small, by
today's standards.  We probably ought to update what those coarse-grain
settings do, and the defaults as well.

(I don't have any changes in gerrit to implement such things.  Pointers to
existing fileserver tuning tips welcome.)

(5) configure arguments for pam/kauth

At the moment, we have separate configure knobs for --enable-pam and
--enable-kauth.  Pam controls whether or not the pam modules are built at
all (provided that the pam dependencies are present), and kauth controls
whether src/kauth bits get installed.  However, the pam modules we provide
are only useful in a kaserver-style environment (i.e., krb4).  Currently,
pam defaults to enabled, and kauth defaults to disabled, and I have not
seen anything to indicate that we wish to reenable kauth for the 1.8
branch.

I think the current proposal is to get rid of --enable-pam entirely, and
make --enable-kauth control whether the pam modules get built at all, in
addition to controlling whether the src/kauth bits get installed.  Does
that seem reasonable?

(6) changing default configure arguments/other configure arguments

We have a lot of configure arguments.  Probably, some of them default to
things that are not optimal.

However, the only one that really stuck out at me from the configure
--help output was pthreaded-ubik.  We believe that what's on master is
stable, and I think we should enable it as the default for 1.8.  (The
alternative is going to disappear on master shortly thereafter, so...)
Any objections to that?

Going through the output more carefully, I also found --disable-gtx,
--disable-uss, --enable-bitmap-later, and --disable-unix-sockets, which I
don't know very much about.  Should --disable-gtx be converted to
--without-ncurses?  Should the others be unconditionally en/disabled, and
the options removed?  Having more options means a combinatorial explosion
of configurations that we claim to support [but probably don't test].

(7) Please review pending gerrit changes

Certainly one of the most helpful things to do to further the creation of
the release branch would be to review pending changes in gerrit, so they
can be merged.

I'll attempt a rough categorization of the relevant gerrit changes to help
prioritize reviewers.  (These are mostly mine; my apologies if I missed
some other ones.)

Outstanding bugfixes (small, high priority):
11452	Let mancheck_utils ignore version subcommands
11453	Tweak AFSDIR_PATH_MAX (recent glibcs cause crashes)
11458	Fix libtool syntax for shlib version info
11475	Fix LT_LDLIB_shlib_missing


Use libtool to build public libraries (high priority):
11461	libafsrpc
11462	libafsauthent
11463	fix pam_afs.so to not depend on private libs
11477	rokenafs
11482	afshcrypto
11484	kopenafs


Support MIT krb5 and external hcrypto/roken (high priority):
11473	configure arguments for separate roken lib/include dirs
11474	build tweaks to allow MIT krb5 + external hcrypto+roken
11481	Allow external hcrypto (except LWP variants)


~dependencies of more important changes (pretty small)
11459	Consistently use a naming convention for helper libraries
11460	Consistently use LT_deps vs. LT_objs
11476	Build auth tests with libtool (to use LIB_roken)
11480	Link aklog with LIB_hcrypto (instead of afshcrypto)


configure-related tweaks (medium priority):
11466	Make pam conditional on INSTALL_KAUTH
11483	configure defaults (pthreaded-ubik)


Outstanding cleanup (small, low priority)
11380	tvolser dependency cleanup
10531	variable naming and whitespace nits in the symlink VOP
11479	Build venus tests with libtool (for libafshcrypto_lwp.a)


remove ~dead code:
11470	netscape plugin from libuafs
11471	separate JUAFS build
11472	build libuafs with lwptool (well, depends on previous two)


Thanks,

-Ben