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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
