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

[chas williams - CONTRACTOR]

On Wed, 24 Sep 2014 15:14:39 -0400 (EDT)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> (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.

Do not ship unless we really have to.  If we start shipping it we will
always need to ship it after that.

> (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).
...
> Does that seem reasonable?  Or should we try to keep consistency with the
> old numbers?

Has OpenAFS ever been installed with shared libraries by any of the
packaged installers?  If not, I don't see a reason to bump the
numbers.  That said, if the API is changed (and changed in a
non-backward compat way) we of course need to bump the numbers.  I
would comment that adding a symbol is changing the API and seems like
it should require an increment.

> (3) Dropping the Netscape plugin and related bits from our tree
> 
...
> So, do we have consensus in favor of removing these bits from the openafs
> tree?

It's unmaintainable since it can't be (reasonably) tested.  Remove it.

> (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.

Good luck with getting agreement about small and large.  Perhaps these
should be more like the client (with respecting to its auto-tuning of
the cache size) and use some percentage of memory on the machine.

> (5) configure arguments for pam/kauth
...
> 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.
...
> addition to controlling whether the src/kauth bits get installed.  Does
> that seem reasonable?

Why keep either for the 1.8 branch?  You can stay on the 1.6 stream if
you need this.  Maintaining stuff that is already done better by others
(pam_krb5, krb5) seems like a waste of time.

> (6) changing default configure arguments/other configure arguments
...
> --help output was pthreaded-ubik.  We believe that what's on master is

Make this the default.  If you don't, it won't get tested in any
meaningful way.

> Going through the output more carefully, I also found --disable-gtx,
> --disable-uss, --enable-bitmap-later, and --disable-unix-sockets, which I

I don't see the reason for --disable-gtx.  --disable-uss
apparently exists because of symbol leakage/pollution.  The right
configure test would be to automatically detect this and just disable
uss building. The other right way is to fix the leakage.  --disable-uss
was easier to write of course and did get the job done.  Perhaps it is
time to split off some of the less popular OpenAFS utilities into their
own branch.

bitmap-later (and fast-restart) are both just poor versions of DAFS.
They should be deprecated for 1.8 (accept the options and print a
warning that the user should switch to DAFS).

I don't know the reason behind unix sockets.  Unix domain sockets gives
you a different permission model I guess.