[See dev-net.html for further discussion; the clean solution is
probably PAM but whether to hold out for that is an open question.

-kingdon]

From: "Cameron, Steve" <Steve.Cameron@COMPAQ.com>
To: "'bug-cvs@gnu.org'" <bug-cvs@gnu.org>
Subject: RE: Submission: Enhanced notification messages
Date: Wed, 16 Dec 1998 08:50:41 -0600
Content-Type: text/plain;
	charset="iso-8859-1"


Well, here's one I submitted back on Oct 30 that doesn't appear to have made
it in.  It's to configure.in, which means someone will have to run autoconf
to produce a new "configure" script...  This patch allows shadow passwords
to work with pserver authentication on SCO Unixware 2.x and Unixware 7.x.
Perhaps there's a valid reason the patch is not worthy...I've tested this on
UW 2 and UW 7, but that's all I've tested it on.

-- Steve


	[Cameron, Steve]  I wrote: .

	Subject: getspnam not found on unixware 2 by configure
	From: scameron
	Reply-To: steve.cameron@compaq.com
	X-send-pr-version: 3.2
	[Cameron, Steve]  [..snip..]
		(This is completely untested, constructed with my very
limited
		understanding of autoconf.  I was not able to build autoconf
on
		unixware.   So I can't test it.  Perhaps someone else can at
least
		make sure it doesn't break everybody else?  Or verify that
it works
		using an autoconf generated configure script?)

		Here's an untested patch to configure.in.  (autoconf needs
to be run
		to make a new configure script...or at least that's how I
think it
	works.)
	[Cameron, Steve]  
	Well, I got autoconf to build on unixware 2 & 7 now.  (turns out I
just needed to get GNU m4 and comment out the bits about makeinfo and tex)
and I ran it and made a new "configure" script.  The new configure script
detected getspnam() properly on unixware 2.  and CVS 1.10 built and ran make
check and make remotecheck OK too.  (though sanity.sh doesn't test anything
that relies on getspnam(), I don't think.)  So if this patch is deemed OK
(i.e. doesn't break other platforms), perhaps it can go in the source tree?
Also, I verified the same problem exists on unixware 7.x and the same patch
fixes it there too.  Here's my attempt at a ChangeLog Entry.

	* configure.in : Changed so that test for getspnam() searches in
libgen if not found in libsec.  This is for SCO unixware 2.x, and unixware
7.x.

	[Cameron, Steve]  And here's the patch (again, no changes since last
post.)
	 
	*** configure.in.orig	Fri Oct 30 10:09:09 1998
	--- configure.in	Fri Oct 30 10:11:54 1998
	***************
	*** 96,102 ****
	  dnl We used to try to determine whether shadow passwords were
actually in
	  dnl use or not, but the code has been changed to work right
reguardless,
	  dnl so we can go back to a simple check.
	! AC_CHECK_LIB(sec, getspnam)
	  AC_CHECK_FUNCS(getspnam)
	  
	  dnl We always use CVS's regular expression matcher.
	--- 96,102 ----
	  dnl We used to try to determine whether shadow passwords were
actually in
	  dnl use or not, but the code has been changed to work right
reguardless,
	  dnl so we can go back to a simple check.
	! AC_CHECK_LIB(sec, getspnam, :, AC_CHECK_LIB(gen, getspnam) )
	  AC_CHECK_FUNCS(getspnam)
	  
	  dnl We always use CVS's regular expression matcher.




> -----Original Message-----
> From:	Jim Kingdon [SMTP:kingdon@cyclic.com]
> Sent:	Wednesday, December 16, 1998 8:14 AM
> To:	cavanaug@sr.hp.com
> Cc:	ianc@scl.co.nz; bug-cvs@gnu.org
> Subject:	Re: Submission: Enhanced notification messages
> 
> > I have seen some very reasonable patches, just get put up on the web and
> > not make it into the CVS tree.
> 
> Do you have a list of patches that you think should go in?  I know
> there are some there which didn't go in mainly because I was busy at
> the time they came (and apparently so were the other CVS maintainers),
> or reasons like that.  Some of them I managed to go back and find
> later, and some Noel checked in, but if someone would like to surf
> those web pages and write up their own
> commentary/analysis/recommendation that might be helpful in sorting
> things out.
> 
> Now, it is also possible that there are diverse points of view about
> the definition of "very reasonable", in which case some kind of fork
> or limited-fork or whatever is the better approach (and to reiterate,
> I don't think this is an automatically bad thing although of course it
> kind of depends a bit on the specific case whether there is a better
> way).