From owner-svn-ports-head@FreeBSD.ORG Thu Jul 17 02:55:39 2014 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 066453B6; Thu, 17 Jul 2014 02:55:39 +0000 (UTC) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2395F2FCE; Thu, 17 Jul 2014 02:55:37 +0000 (UTC) X-AuditID: 12074424-f79146d00000067c-0b-53c739f5873e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B8.F2.01660.5F937C35; Wed, 16 Jul 2014 22:50:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6H2oS8i001858; Wed, 16 Jul 2014 22:50:29 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6H2oQv1027772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Jul 2014 22:50:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6H2oPYS022272; Wed, 16 Jul 2014 22:50:25 -0400 (EDT) Date: Wed, 16 Jul 2014 22:50:25 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Alexey Dokuchaev Subject: Re: svn commit: r361646 - in head/net/samba36: . files In-Reply-To: <20140716134634.GA53978@FreeBSD.org> Message-ID: References: <201407122229.s6CMTN42057554@svn.freebsd.org> <53C322A7.2090705@marino.st> <20140714003112.GA54756@mouf.net> <53C451FA.2020304@marino.st> <20140715170501.GA73101@FreeBSD.org> <53C5618F.2020104@FreeBSD.org> <20140716134634.GA53978@FreeBSD.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrPvV8niwweEN+haT5rxmtfj95xu7 xcS+w0wWvya+YrRo+/SP3WLZkS2sDmweMz7NZwlgjOKySUnNySxLLdK3S+DK+NG3n62gS7Xi Wd8UtgbGS7JdjJwcEgImEptbjrJD2GISF+6tZ+ti5OIQEpjNJLFs0iYoZyOjxKLOHlYI5xCT xMVTq6EyDYwSV99fZQHpZxHQlnjT0AY2i01ATeLx3mZWiLmKEptPTWIGsUUENCRWdHeygDQz C3QwSWz5tBEsISxgL7Fw9R6gBAcHp4ChRP+9epAwr4CjxJ5Nt6A2dzFLXF/zghEkISqgI7F6 /xQWiCJBiZMzn4DZzAKWEv/W/mKdwCg0C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmp RbrmermZJXqpKaWbGEFBzu6isoOx+ZDSIUYBDkYlHt4d7ceChVgTy4orcw8xSnIwKYnyTjI/ HizEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhNeVCSjHm5JYWZValA+TkuZgURLnfWttFSwkkJ5Y kpqdmlqQWgSTleHgUJLgvWMB1ChYlJqeWpGWmVOCkGbi4AQZzgM0/C9IDW9xQWJucWY6RP4U oy7Hu9vH2piEWPLy81KlxHnLQIoEQIoySvPg5sCS0ytGcaC3hHkVgKlKiAeY2OAmvQJawgS0 pLzmMMiSkkSElFQD45xLKxbeYuRptT56aIme0v39H7d1/XnwS8/+gN58vwS5qc+f6zzVfyWn euza6h1/7G4dks2aL7vky1rvL26fD0guVeDztTkSZF98l9WzXl5G2tAyQuLT6TmMfkpCRT4P S2OOxGWr3DzyqIv9f3h7zsqujmuOGzUrTjsUJbqpbOqZZKi3fF7AUSWW4oxEQy3mouJEABwX EAMpAwAA Cc: svn-ports-head , Vsevolod Stakhov , svn-ports-all , Benjamin Kaduk , "ports-committers@freebsd.org" X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 02:55:39 -0000 On Wed, 16 Jul 2014, Alexey Dokuchaev wrote: > [ CC list trimmed; bjk@ added (see below) ] > > On Tue, Jul 15, 2014 at 06:14:55PM +0100, Vsevolod Stakhov wrote: >> Let me explain the situation with pkg. Pkg needs to find so called >> ``upgrade chains'' that are used to upgrade packages. To find out >> packages that are suitable for upgrade we use origins in pkg 1.2 and >> name~origin in pkg 1.3. >> >> However, each package is identified by a special field called >> `manifestdigest'. In pkg 1.2, this field is just sha256(manifest). >> Unfortunately, this means that if *any* field of a package is changed a >> version bump is required. By fields I mean files and directories as well >> which leads thus to a policy where we need to bump a revision even if we >> have meaningless changes in the files a package provides (that happens >> after this particular change). >> >> With pkg 1.3 this behaviour has been changed to recognize the following >> fields only: >> >> * name >> * origin >> * version >> * arch >> * maintainer >> * www >> * message >> * comment >> * options >> >> Hence, I think that with the release 1.3 of pkg we should define >> revision bump policy to reflect this change. > > I've recalled that bjk@ mentioned once that he was giving a talk about some > interesting features of Debian packaging at the ports devsummit at BSDCan. > Maybe we can learn a thing or two from those guys? Ben, can you share your > opinion on Vsevolod's proposal (you might want to see other messages in the > thread first)? Thanks. I do not think that Alexey would like the Debian way ;) The *only* things that are officially part of Debian are packages. This includes both the binary packages containing the actual compiled software, and source packages, which contain the exact sources used to build the software. The packaging files, patches, etc., are included in the source package, but any use of version control to maintain them is up to the individual package maintainer -- there is no official authoritative Debian repository for them. [1] (The Debian project does provide hosting that many people use, but it is not official.) Package maintainers upload pgp-signed source packages to the master FTP site (along with a single binary package for one architecture to prove it builds), the signatures are verified, and then a set of build daemons goes off to build the binary packages for all other architectures. End users only ever interact with binary packages, and pretty much the only people building things from source are the maintainers of the package in question. Because of the way the distribution process works (maintainer uploads a signed package, official builds are made from that source package, the checksums of the resulting binary packages are placed in a signed manifest that is fetched by end users' clients), literally any change in the binary package requires a new version number, as otherwise the signatures would be invalidated and the new package would not be installable via the normal channels. Trying to transition this logic to the FreeBSD universe, where we do maintain an official source code repository for the packaging, the conclusion would be only change that should trigger a package rebuild should get a version bump. This is different from saying that any change which causes a difference in the binary package requires a version bump, since there are some changes which are not urgent and for which there is no real benefit of immediately starting to distribute them to users. I am inclined to agree with the suggestion elsewhere in the thread that changes to maintainer, www, message, and comment need not immediately trigger distribution of the update to users (and if change to those fields should trigger immediate distribution of updates to users, the maintainer is responsible for incrementing the version number). That is just using the current list (quoted above) as a starting point. I don't know if there are other fields which might be considered for triggering mandatory version increments, but it seems a little unlikely since none have come up yet. -Ben [1] One could say that the actual Debian package repository constitutes a version control system, with the version numbers being the package version numbers, and one can retrieve the packaging at a given revision by extracting that source package. All the packages' checksums are signed, so if the signatures and the packages themselves are kept around indefinitely, all revisions are retrievable. But it seems rather ridiculous to claim that this is a usable VCS.