From owner-freebsd-ports@FreeBSD.ORG Tue May 26 05:37:19 2015 Return-Path: Delivered-To: freebsd-ports@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 3ED9BC6D; Tue, 26 May 2015 05:37:19 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5E1F14; Tue, 26 May 2015 05:37:19 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by pacwv17 with SMTP id wv17so84396473pac.2; Mon, 25 May 2015 22:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=kqYzHbkLjo2jydHv8xBanXhi45Wj9NfrwQ6DCYEzrU0=; b=bX1C5gmzjYq6/rPP47BDE+zWqByCgG2/EF7vxLuEbSXr5xGloP/aBhA4S35S1I4VJJ LWQpxJpswGW1/V5L/jPg8JP8/PpQP+s9J5ftuNd94C2hldXAeLO1CP/YmMrzeo7iQY0G gBm6bNMxEICQ8YUy6sJsglAgD6I1L9EQdGEcqYFKLIV1jUaypMpVAGaQAoV5y3Z6Qys0 pjy0Ixdijp4IZeUIC/bqrdvQiy8s5kFRVqv57RUNdpFlhG/du6HmaD9n8oXLQNl3Cum4 vWaqK8fpjeZ9f7fJzKdhkU8KNH1drIuVKmwld0BsHfYiGoPDbV5djwwaqxLw87leb3pa q59A== X-Received: by 10.70.37.225 with SMTP id b1mr45984822pdk.35.1432618638475; Mon, 25 May 2015 22:37:18 -0700 (PDT) Received: from [192.168.1.104] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id p5sm11709353pdi.2.2015.05.25.22.37.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2015 22:37:17 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Any guidance for gnupg-2.0 -> gnupg-2.1 (archived encrypted email)? References: <20150524181321.GB1214@albert.catwhisker.org> <20150525205952.GA4054@rwpc15.gfn.riverwillow.net.au> <1f553d90a8570bbd741b75b842dad455@ultimatedns.net> To: Chris H , freebsd-ports@freebsd.org Cc: kuriyama@FreeBSD.org From: Kubilay Kocak X-Enigmail-Draft-Status: N1110 Message-ID: <55640687.9070704@FreeBSD.org> Date: Tue, 26 May 2015 15:37:11 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <1f553d90a8570bbd741b75b842dad455@ultimatedns.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 05:37:19 -0000 On 26/05/2015 12:54 PM, Chris H wrote: > On Tue, 26 May 2015 06:59:52 +1000 John Marshall > wrote > >> On Sun, 24 May 2015, 11:13 -0700, David Wolfskill wrote: >>> Last November, I encountered a reason to deviate from that: When >>> security/gnupg became gnupg-2.1, I found that gnupg-2.1 was unable to >>> decrypt some (well, any, in my experience) archived encrypted email >>> messages. >> >> I was bitten badly in November when I blindly upgraded security/gnupg >> and found myself in the new, shiny, non-STABLE version 2.1.0. I can't >> remember the details, but too much stuff didn't work. I went to the >> release notes and other places and spent about a day trying to make the >> best of it. I had some success but ended up reverting security/gnupg -> >> security/gnupg20 after I discovered the following on the GnuPG home >> page. >> >> - 2.0.27 is the stable version suggested for most users, >> - 2.1.4 is the brand-new modern version with support for ECC and many >> other new features, and >> - 1.4.19 is the classic portable version. >> >> The STABLE 2.0 branch still works for me and the surprise factor is not >> as prominent as in 2.1. I have no idea why the main FreeBSD port was >> switched from STABLE to CURRENT and the STABLE version was relegated to >> a new version-tagged port. >> >> Sorry if this is off-topic but maybe it helps some folks. > Isn't the standard way to deal with this in the ports tree, to > create /portname, and /portname-devel ? > Having portname track "stable", and the -devel branch track "current"? > Can gnupg be rearranged to follow this method? There are a couple of cases to consider: Note: I will refer to branches as !development, rather than stable/current/release, since often there isn't an absolutely clear distinction, or those designations can be relatively transient. a) Those projects that have many (read >2) "supported" versions/branches. b) Those projects that maintain 2 versions/branches, latest !development and development (next version) The category/portname and category/portname-devel convention only covers for (b), and is not necessarily a good convention for all cases. For instance ZeroMQ maintains quite a few previous "stable" branches. Having category/portname move across major/minor versions can (and does) break compatibility for dependent ports. In this case category/portnameXY is a better convention, perhaps with category/portname left to point to a DEFAULT_VERSION, which the user can change. Similar examples include apache, squid, postgresql, php among others. In this case, I'd have opted for gnupg20 and gnupg21 rather than a -devel distinction or moving gnupg across major/minor versions. Personally preference granted, but a considered one. My 2c Koobs