Any guidance for gnupg-2.0 -> gnupg-2.1 (archived encrypted email)?

Kubilay Kocak koobs at FreeBSD.org
Tue May 26 05:37:19 UTC 2015


On 26/05/2015 12:54 PM, Chris H wrote:
> On Tue, 26 May 2015 06:59:52 +1000 John Marshall
> <john.marshall at 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

Koobs



More information about the freebsd-ports mailing list