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.
>
> Could you clarify what exactly is the part that "we don't do"? Are you
> referring to having multiple versions of the same port, or using names
> instead of numbers?
>
> The way I see it, there is precedence for both. Regarding the former, among a
> myriad of examples I will cite Python: python27 is "legacy", python36 is
> "current". Regarding the latter, I can think of libressl: the plain name is
> "stable" (2.5.x), libressl-devel is "current" (2.6.x).
>
> Is there anything I'm missing?
>
> P.S.: Personally I'm agnostic if we adopt the "numbered" or "named" strategy.
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 conflict.
For other ports, we use numbered port names, e.g. python27, python36, which
install files to different locations and thus do not conflict.
There are some ports that use numbered names and yet still conflict with one
another. This should be avoided if possible.
There are four ports which have -legacy versions: darwinbuild, libusb, octave,
pdfgrep. I consider this naming style to be unusual and don't know why it was
chosen in these cases.
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 -stable suffix. But using just "gnupg" as the stable 2.2 port
name would cause an upgrade problem, since all users who currently have the
"gnupg" port installed expect that to be 1.4.
For ease of upgrading, my preference is probably that gnupg2 be updated to 2.2
and gnupg21 be replaced_by gnupg2. If desired, gnupg2-devel could be added to
track the development version. If desired, gnupg1 could be introduced and gnupg
could be replaced_by gnupg1. If desired, far in the future, after everybody has
upgraded (i.e. more than one year after the preceding changes have been
committed), gnupg2 could be copied to and replaced_by gnupg and gnupg2-devel
could be copied to and replaced_by gnupg-devel.
