[OpenAFS-devel] afs_pam2 - A simplier approach to AFS integration during login

[Russ Allbery]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:

> I don't particularly care for libtool.  It imposes a lot of structure
> trying to solve problems that most people don't actually have, and
> imposes unnecessary restrictions that make my life annoying.  It plays
> poorly with objdir builds and DESTDIR installs.

Huh.  My experience is that it plays better with those builds than doing
things without libtool does (having had a fair bit of experience doing it
both ways).  libtool has special handling for DESTDIR that gives you some
hope of actually getting the right shared library paths on platforms like
HP-UX.

I'm not saying it doesn't suck, just that I've had it suck less than
trying to roll one's own build rules.

> In addition, the problem libtool solves is one we don't actually have.
> The libraries you're talking about (libafsrpc and libafsauthent) are
> _already_ available in shared, pthreads-aware versions.

Well, they're not available in a way that people can use to solve the PAM
problem because they're not built PIC.  Unless I'm missing something?

> Finally, I'm not sure I agree with your assertion that these are the
> "new" API's that everything should use.  While they begin to move in the
> right direction with respect to library makeup, it's not quite right,
> and if we're going to spend effort in this area, we should try to do
> something that doesn't suck, and that's consistent along both the
> static-vs-shared and lwp-vs-pthread axes.

Okay, well, on that I'm just repeating what I was told, so I may well be
completely wrong.

I'm volunteering to do the work required to get shared libraries that can
at least be used for PAM purposes, including calling setpag and building
thread-safe PAM modules.  If a prerequisite for that work is working out
the library API, that may be more than I can handle.  :/

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>