From owner-cvs-src@FreeBSD.ORG Sun Apr 20 16:00:02 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDAE437B401; Sun, 20 Apr 2003 16:00:02 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 900C943FBF; Sun, 20 Apr 2003 16:00:01 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 0634753; Sun, 20 Apr 2003 18:00:01 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 4CC0578C66; Sun, 20 Apr 2003 18:00:00 -0500 (CDT) Date: Sun, 20 Apr 2003 18:00:00 -0500 From: "Jacques A. Vidrine" To: Doug Barton Message-ID: <20030420230000.GB32112@madman.celabo.org> References: <200304181411.h3IEBH07088819@repoman.freebsd.org> <20030420141848.K631@znfgre.tberna.bet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420141848.K631@znfgre.tberna.bet> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/include pwd.h src/lib/libc/gen getpwent.c src/usr.sbin/pwd_mkdb pwd_mkdb.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:00:03 -0000 On Sun, Apr 20, 2003 at 02:19:55PM -0700, Doug Barton wrote: > I've already told Jacques that I'd look into the problem with named, but > more generally, I doubt this will be our only problem child. Has this new > code been regression tested against any other third party code? I suppose no more or less than is expected for -CURRENT. It happens that I don't use BIND8, so I missed this issue. It didn't occur to me that applications would use our internal definitions. (Note the underscores in _PW_KEYBYNAME et. al.) Moreover, it didn't occur to me that applications would not use getpwent(3) and friends to access system databases. (I believe this is a bug in our BIND installation.) For this particular issue, as described in the commit, I've reverted these macros to the previous values in case there is any other code that (ab)uses them. As designed, the on-disk format is compatible, so e.g. static binaries build against FreeBSD 3.x still function with /etc/pwd.db. [ I may have misunderstood your question. It's pretty much a no-no to commit code with no testing, even to -CURRENT. Maybe you have something more specific in mind. ] Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se