Date: Tue, 26 May 2015 00:19:35 -0700 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-ports@freebsd.org> Subject: Re: Any guidance for gnupg-2.0 -> gnupg-2.1 (archived encrypted email)? Message-ID: <bb0f7c59a604e06d5bb1031d6904936e@ultimatedns.net> In-Reply-To: <55640687.9070704@FreeBSD.org> References: <20150524181321.GB1214@albert.catwhisker.org> <20150525205952.GA4054@rwpc15.gfn.riverwillow.net.au> <1f553d90a8570bbd741b75b842dad455@ultimatedns.net>, <55640687.9070704@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 May 2015 15:37:11 +1000 Kubilay Kocak <koobs@FreeBSD.org> wrote > On 26/05/2015 12:54 PM, Chris H wrote: > > On Tue, 26 May 2015 06:59:52 +1000 John Marshall > > <john.marshall@riverwillow.com.au> 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 <category>/portname, and <category>/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 I completely understand, and very much appreciate your input on this. I also tried to figure how it would even be feasible to "rearrange" gnupg to follow the stable / -devel track, given that the "shoe has already dropped", so to speak -- the new version has already been applied to the gnupg port. But since there appeared to be 1) some "compatibility" issues, 2) the web site indicates 2.0 is the "stable" branch, and 3) so many other ports in the ports tree "depend" on the "standard" gnupg branch. That maybe the switch to 2.1 might have been a bit premature, and that the standard / -devel route might be the / a solution. That's all. Not trying to be "pushy" or anything. Just attempting to suggest a possible solution. :) > > Koobs > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" --Chris --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb0f7c59a604e06d5bb1031d6904936e>