From owner-svn-ports-all@FreeBSD.ORG Tue Apr 15 13:08:37 2014 Return-Path: Delivered-To: svn-ports-all@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 E8BEBFB7; Tue, 15 Apr 2014 13:08:37 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (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 530E2180B; Tue, 15 Apr 2014 13:08:37 +0000 (UTC) Received: from [192.168.0.20] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 439D943BB3; Tue, 15 Apr 2014 08:08:12 -0500 (CDT) Message-ID: <534D2F2B.4030606@marino.st> Date: Tue, 15 Apr 2014 15:07:55 +0200 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bryan Drewery , Baptiste Daroussin , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r351326 - head/Mk References: <201404151249.s3FCnkvQ026905@svn.freebsd.org> <534D2D57.60001@FreeBSD.org> In-Reply-To: <534D2D57.60001@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: marino@freebsd.org List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:08:38 -0000 On 4/15/2014 15:00, Bryan Drewery wrote: > On 4/15/2014 7:49 AM, Baptiste Daroussin wrote: >> Author: bapt >> Date: Tue Apr 15 12:49:46 2014 >> New Revision: 351326 >> URL: http://svnweb.freebsd.org/changeset/ports/351326 >> QAT: https://qat.redports.org/buildarchive/r351326/ >> >> Log: >> Register deprecation and expiration in packages >> > > This will require bumping PORTREVISION for DEPRECATED and EXPIRE_DATE > changes, resulting in a 100% useless rebuild. > > It would be much better to not have this in the packages at all and only > in the repo. I think this conclusion depends on individual interpretation. Did the installed binary change? No, so no bump needed. Does the pkg internal database contents change? yes. Does that require a bump? That depends on how vital the information is. If it's considered "nice to have" and people can live with it only coming in when the PKGNAME changes, then no bump is required. If the lack of transparency on DEPRECATION is considered a real issue (and sure many people do believe this) then yes, a bump would be needed to get it visible. We're only talking about 120 packages here, so the price is not very high. My vote is to that if this helps binary package users see deprecated packages clearly then it's worth the rebuild. John