Variants +clang3{0,1,2} ...

[Ryan Schmidt]

On Apr 25, 2015, at 11:53 AM, petr wrote:
> 
> On 25 Apr 2015, at 17:49, Lawrence Velázquez wrote:
> 
>> On Apr 25, 2015, at 5:49 AM, petr wrote:
>> 
>>> To my understanding the +clang3{0,1,2} refer to clang-3.{0,1,2} respectively.
>> 
>> Yup.
>> 
>>> These clang ports are no obsolete.
>> 
>> Yup.
>> 
>>> However, there are still quite some ports around with these variants, so I guess these clang3{0,1,2} variants (and maybe others) should be removed?
>> 
>> Yup.
> 
> Okay,
> anything else which should be considered for a "variant cleanup"? 
> 
> I guess the same applies to dragonegg3? < dragonegg33. I would also propose to remove all +gcc4? < gcc47 and all related openmpi and mpich variants. I am CCing Sean and Eric explicitly for their involvement in compiler Portgroup, openmpi or mpich, respectively.

The clang30, clang31 and clang32 variants should be removed from any ports where they exist because the clang-3.0, clang-3.1 and clang-3.2 ports they depend on are already marked as being replaced by clang-3.4, so they already cannot be installed and those variants are already broken.

The gcc variants you mention, on the other hand, should still be working fine, since the corresponding gcc ports still exist and should still work fine. So I have no particular rush or inclination to do any mass removal of these variants. Or would removing them solve some problem you're having?


> Does it make sense to turn this into a macro ticket?
> Not sure if people are fond of getting all these ticket change notifications (cf. perl version ticket).

I am personally not fond of receiving all those notifications. I'm not sure what the best policy is for making changes across a vast number of ports of varying maintainers. Probably the one that I like best is to file a macro ticket, with all relevant ports and maintainers indicated, but also with a patch already attached. The ticket would serve as notification to all these maintainers that this change will be made, that maintainers need not (or even should not) act on their own, and that if there is are objections within a number of days then a single commit would be made by the initiator of the ticket to make the change. This would avoid all the notifications that would occur as each individual maintainer makes the change in their own ports, and would also avoid follow-up commits that are sometimes needed to correct mistakes maintainers might make in the implementation of the proposed change.