Date: Wed, 16 Jul 2014 22:50:25 -0400 (EDT) From: Benjamin Kaduk <bjk@freebsd.org> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: svn-ports-head <svn-ports-head@freebsd.org>, Vsevolod Stakhov <vsevolod@freebsd.org>, svn-ports-all <svn-ports-all@freebsd.org>, Benjamin Kaduk <bjk@freebsd.org>, "ports-committers@freebsd.org" <ports-committers@freebsd.org> Subject: Re: svn commit: r361646 - in head/net/samba36: . files Message-ID: <alpine.GSO.1.10.1407162217270.21571@multics.mit.edu> In-Reply-To: <20140716134634.GA53978@FreeBSD.org> References: <201407122229.s6CMTN42057554@svn.freebsd.org> <CALdFvJGQq=PNpAqBBEZXi-q0GT=Ro-fRSjGcHFR1R01=FBtQOQ@mail.gmail.com> <53C322A7.2090705@marino.st> <20140714003112.GA54756@mouf.net> <CALdFvJEvf4-RSJNUVxX08T8K-tq9PoKge-XxmhDafAn_QxjEcg@mail.gmail.com> <53C451FA.2020304@marino.st> <20140715170501.GA73101@FreeBSD.org> <53C5618F.2020104@FreeBSD.org> <20140716134634.GA53978@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1407162217270.21571>