From owner-svn-ports-head@FreeBSD.ORG Mon Aug 11 15:27:07 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 DE3CB1F9 for ; Mon, 11 Aug 2014 15:27:06 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1DBD27C0 for ; Mon, 11 Aug 2014 15:27:06 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id 421 by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Mon, 11 Aug 2014 15:27:06 +0000 Received: (qmail 87269 invoked from network); 11 Aug 2014 10:27:04 -0500 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 11 Aug 2014 10:27:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Aug 2014 10:27:04 -0500 From: Bryan Drewery To: Matthew Seaman Subject: Re: svn commit: r364287 - head/ports-mgmt/pkg-devel Organization: FreeBSD In-Reply-To: <53E88B33.8000109@freebsd.org> References: <53e39939.55bc.4ca5432c@svn.freebsd.org> <20140807172841.58633e63@kalimero.tijl.coosemans.org> <53E3A468.5050603@FreeBSD.org> <53E3AC0C.5020904@gmx.de> <53E3AD09.2050000@FreeBSD.org> <53E3B3B5.9000104@gmx.de> <53E3B6D8.9080101@FreeBSD.org> <53E590AC.4020105@FreeBSD.org> <53E7A512.8050008@FreeBSD.org> <53E7D193.3090305@FreeBSD.org> <53E7F110.7010105@FreeBSD.org> <53E87E4B.5090600@FreeBSD.org> <53E88B33.8000109@freebsd.org> Message-ID: <2b62be838237da061c474c2974cc6996@shatow.net> X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/1.0.1 Cc: svn-ports-head@freebsd.org, Vsevolod Stakhov , svn-ports-all@freebsd.org, ports-committers@freebsd.org, Matthias Andree , Tijl Coosemans 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: Mon, 11 Aug 2014 15:27:07 -0000 On 2014-08-11 04:21, Matthew Seaman wrote: > On 08/11/14 09:26, Vsevolod Stakhov wrote: >> I agree with this. But we need to define the policy of significant >> fields thus. The pull request I've mentioned previously changes this >> policy. But I still have no sane comments about it from the ports >> developers... >> >> https://github.com/freebsd/pkg/pull/911 I will test this. > > As I see it, if there's a change to any of the fields that go towards > creating the package digest, then we're requiring all the users to > update that package. This should be avoided for trivial changes. > > So, switching the question round: what fields in the manifest should > *not* imply reinstalling the package? > > - comment > - description > - categories (these don't have much effect for binary packages) > - www > - maintainer (hmmm... not sure. We wouldn't want to have former > maintainers still being pestered about their old > ports.) I would like to move all of this to a different mechanism. It is a lot of BW overhead to download a new package only because a maintainer changes, and then to also reinstall all files. I don't think we have smart upgrades yet where only changed files are extracted (#735). It also adds a lot of strain to the package building infrastructure to be bumping revision for any of those fields. Yes it is the "proper" thing, but it is not reasonable given all of the overhead. Generally those things should be bunched up into other significant changes right now. > - annotations > > Anything that relates to the actual package contents -- so changes to > the list of files and their checksums (assuming we have reproducible > builds? I can't remember if we do or not), changes to scripts, > dependencies, required shlibs, etc. definitely is a cause for a > reinstall of a package. (Although shlib changes would necessarily mean > changes to file checksums. Arch, flat size too). Similarly changes to > licenses. > > Package name and origin together are the unique identifier, so should > remain constant -- or else it's going to be treated as a different > package[*]. Curiously though, while the package version should change > with any update to the package content, just changing the version > number > on alone probably isn't cause for reinstalling the package. > > Cheers, > > Matthew > > [*] Maybe we should be tracking old name / origin data (ie. relevant > bits of /usr/ports/MOVED) within package metadata? -- Regards, Bryan Drewery