From owner-svn-src-all@FreeBSD.ORG Thu Jun 4 07:53:00 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 488DFD3F; Thu, 4 Jun 2015 07:53:00 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF7911199; Thu, 4 Jun 2015 07:52:59 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.home.us.delphij.net (c-71-202-112-39.hsd1.ca.comcast.net [71.202.112.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id A1F4917DB6; Thu, 4 Jun 2015 00:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1433404379; x=1433418779; bh=9Sp+DKyQG711enRF492iQ7eYIdnbcXMn6UNF6nWDNWQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=CqCYTi+e8mtsqwBBmhK8Bo+rdI3E8nEV3mDZueRGr3FUooKDhX1U8D8BvgHvQIkDH bF+q6cV+w7PZcAkSMdcE+bo3D4qZbVs3jnMfgnxUh+2Z4qemK9Kw1coZjzCJmON6PM Xahbv8H03hkBwkg0+HsmD/FzVSQVYn2y+p87yMfY= Message-ID: <557003DA.9090205@delphij.net> Date: Thu, 04 Jun 2015 00:52:58 -0700 From: Xin Li User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Baptiste Daroussin , d@delphij.net CC: Sergey Kandaurov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, nectar@FreeBSD.org Subject: Re: svn commit: r283969 - head/lib/libutil References: <201506032048.t53KmSCf074619@svn.freebsd.org> <20150603215841.GF32562@ivaldir.etoilebsd.net> <556F8322.9050602@delphij.net> <20150604052120.GH32562@ivaldir.etoilebsd.net> In-Reply-To: <20150604052120.GH32562@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 07:53:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/3/15 22:21, Baptiste Daroussin wrote: > On Wed, Jun 03, 2015 at 03:43:46PM -0700, Xin Li wrote: >> On 06/03/15 14:58, Baptiste Daroussin wrote: >>> On Thu, Jun 04, 2015 at 12:51:46AM +0300, Sergey Kandaurov >>> wrote: >>>> On 3 June 2015 at 23:48, Baptiste Daroussin >>>> wrote: >>>>> Author: bapt Date: Wed Jun 3 20:48:28 2015 New Revision: >>>>> 283969 URL: >>>>> https://svnweb.freebsd.org/changeset/base/283969 >>>>> >>>>> Log: Add a pw_mkdb2(3) function which does the same thing >>>>> as pw_mkdb(3) except it takes a new argument allowing to >>>>> specify the endianness of the database to generate >>>>> >>>> >>>> Why not change pw_mkdb()? Is it used outside of the project? >>>> >>> Because that would change the ABI of libutil and it is not a >>> private library aka we are supposed to maintain ABI >>> compatibility as we do not know if it is used or not externally >>> to the project. I care about the ABI because I have made this >>> change in order to use it in pw(8) and MFC it to stable/10 >>> before 10.2. >>> >>> libutil is not versionned so this is the only way to not break >>> the ABI. Except if someone has a better idea than I do. >> >> Looking at r113596, pwd_mkdb(8) was changed to generate both >> legacy (version 3, endianness sensitive) and new (version 4, >> machine independent) formats. >> >> Now, after 12 years, is it still sensible to generate legacy >> format db entries? Maybe we should just disable the generation >> by default and eventually remove the ability to generate them? >> > > That could be an option, in this case we could add a -l (legacy) > option to pwd_mkdb to allow the users to generate the db in legacy > format and drop support support for legacy format in all other > tools. Meaning I can revert pw_mkdb2(3) Well, I think the pw_mkdb2(3) should be reverted, because the base system libraries are not using the legacy format when new formatted entries are present (which is true for databases generated on FreeBSD 5+); and if they do, that shall be seen as a bug and we should fix these libraries. I have committed r283981-r283983 to implement the default change and the -l option. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVcAPZAAoJEJW2GBstM+nsb1oQAKug0zb3dxTSZScZJ/R8YBof +upLW/MALifOlhkYz0QBp+VQwrXvX+ZT1tseIwopg6pL0mrq9ZRrSb5DepFIc8fY lJ0P1s15RF41hRFcRSh3bJh8rEGekgS5fv3EFWwvrwUSA1D22X+wOofCLfZs2uji MpPmhc1g5jMN3tx4Evsx/7prSoXFGZYimnVIb8uNmjJyruHlrSrXsIau/b8ND4lm 7eQS4n5EoNmu8ui7rk4IsJPr1kP/gpjE+UPGi0tICjb8In8lE0Tj2fgMuDpRHQ7K II90Qanv+RZrapRb8zIOJRH8GBA0IlE8LzcIcoI4Dd32eP+HfP6BPMOD+kB9VlsS xapUo/PSF6ouScPNIoQD0Pq1VdvYHUTid/McoI6UTauHYSerl8mGOvpSRZF1GIFa pFzpJcsl15tWXAhwrDxSSwO+2BvtXDO36K+VbmTlMlr8Z623S6F2K/MyEkIbpj55 Un85J2xNoYbeEjc8+66emjILUZajGXXiJLS4v1f5RYTyOTl4t7coV4aDPb2c0aZu JsbagSfkPCuHttzwbry4EnfI+4eRo7+wtR3rf9tOXBt6DOY7qTba6GSBIpvVeqbe tlM/rpXnREgIUFyshKGN50I2OcpJY9RWALNUMwlCXDUbW4sHwy7acma0+hhDoGAl Q5Hc9f0/u76LNnvDQWNZ =6rIW -----END PGP SIGNATURE-----