On 10/10/2017 at 08:58 db wrote:
> On 10 Oct 2017, at 07:18, Leonardo Brondani Schenkel
> wrote:
>> On 2017-10-10 03:10, Helmut K. C. Tessarek wrote:
>>> On 2017-10-09 08:11, Rainer Müller wrote:
gnupg -> 2.2
gnupg-devel -> 2.3
gnupg1 -> 1.4
>>> +1
>> +1
>
> +1
>
Ok I
On 10 Oct 2017, at 07:18, Leonardo Brondani Schenkel
wrote:
> On 2017-10-10 03:10, Helmut K. C. Tessarek wrote:
>> On 2017-10-09 08:11, Rainer Müller wrote:
>>> gnupg -> 2.2
>>> gnupg-devel -> 2.3
>>> gnupg1 -> 1.4
>> +1
> +1
+1
On 2017-10-10 03:10, Helmut K. C. Tessarek wrote:
On 2017-10-09 08:11, Rainer Müller wrote:
gnupg -> 2.2
gnupg-devel -> 2.3
gnupg1 -> 1.4
+1
+1
On 2017-10-09 08:11, Rainer Müller wrote:
> gnupg -> 2.2
> gnupg-devel -> 2.3
> gnupg1 -> 1.4
+1
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for
On 10/09/2017 11:00 AM, Ryan Schmidt wrote:
>
> On Oct 9, 2017, at 03:45, Leonardo Brondani Schenkel wrote:
>> On 2017-10-09 10:25, Ryan Schmidt wrote:
>>> On Oct 8, 2017, at 18:46, Mihai Moldovan wrote:
The strategy will be gnupg-{legacy,stable,current} like you suggested.
>>> Do we really w
On Oct 9, 2017, at 8:11 AM, Rainer Müller wrote:
> I would just move 1.4 to gnupg1 and let gnupg provide version 2.2, as
> only few users will be looking for GnuPG 1.4.x these days. If there is
> enough interested, create gnupg-devel for the 2.3 development branch.
+1
--
Daniel J. Luke
On 2017-10-09 11:00, Ryan Schmidt wrote:
> No ports use -stable or -current suffixes. I wouldn't want a -current suffix
> since it's not clear linguistically what the difference would be between
> "stable" and "current". And since ports are assumed to be stable, I would
> want to avoid adding a
Thanks for the clarification. Comments inline.
On 2017-10-09 11:00, Ryan Schmidt wrote:
Ports are assumed to be stable. If we want to also offer a development version,
we use the -devel suffix. The stable (no suffix) and development versions
install files to the same places and therefore confl
On Oct 9, 2017, at 03:45, Leonardo Brondani Schenkel wrote:
> On 2017-10-09 10:25, Ryan Schmidt wrote:
>> On Oct 8, 2017, at 18:46, Mihai Moldovan wrote:
>>> The strategy will be gnupg-{legacy,stable,current} like you suggested.
>> Do we really want to do that? We don't do that for other ports.
>
On 2017-10-09 10:25, Ryan Schmidt wrote:
On Oct 8, 2017, at 18:46, Mihai Moldovan wrote:
The strategy will be gnupg-{legacy,stable,current} like you suggested.
Do we really want to do that? We don't do that for other ports.
Could you clarify what exactly is the part that "we don't do"? Are
On Oct 8, 2017, at 18:46, Mihai Moldovan wrote:
> The strategy will be gnupg-{legacy,stable,current} like you suggested.
Do we really want to do that? We don't do that for other ports.
On 09/29/2017 12:03 PM, Leonardo Brondani Schenkel wrote:
> Does it make sense? Can we agree on a concrete strategy (this or a
> proposed alternative) that we can start implementing?
The strategy will be gnupg-{legacy,stable,current} like you suggested. We've
been talking about that on IRC and it
Seems like a reasonable compromise.
So for now there will be two non-deprecated ports: gnupg and gnupg2.
They both install the gpg executable and conflict with each other.
One question I still have is what is going to happen the the separate
gpg-agent port? Do we still want to support this for the
On 2017-09-14 04:10, Mihai Moldovan wrote:
If GPG 2.0 is to be replaced by 2.2, which is really a fork of 2.1, there isn't
a lot of sense to keep it around.
Just a small clarification: 2.2 *is* 2.1, it has been "promoted", not
forked. GPG is using odd numbers for development branches (= major
On 09/05/2017 08:21 PM, Rainer Müller wrote:
> Totally in favor. I have been using gnupg21 for a while and had to keep
> local modifications for some dependencies.
>
> But let us hear how Mihai as the current maintainer of the gnupg* ports
> thinks about that.
I guess that all makes sense.
If GP
I also agree with what you wrote. The three ports
- gnupg-legacy (possibly call this gnupg14 - since this is unlikely to
change)
- gnupg-stable
- gnupg-current
should all conflict with each other.
I'm in favour of keeping version numbers out of port names because if
upstream iterate quickly you'
On 2017-09-05 20:21, Rainer Müller wrote:
On 2017-09-04 23:17, Leonardo Brondani Schenkel wrote:
My suggestion for how MacPorts should handle this, moving forward, and
to reduce disruption:
- port "gnupg" stays the same
- port "gnupg2" becames 2.2.x and installs as $prefix/bin/gpg, and a
symlin
On 2017-09-04 23:17, Leonardo Brondani Schenkel wrote:
> My suggestion for how MacPorts should handle this, moving forward, and
> to reduce disruption:
>
> - port "gnupg" stays the same
> - port "gnupg2" becames 2.2.x and installs as $prefix/bin/gpg, and a
> symlink in $prefix/bin/gpg2 for backwar
18 matches
Mail list logo
