GSoC 2019 [Collect build statistics]

[Fred Wright]

On Sun, 24 Mar 2019, Mojca Miklavec wrote:
> On Sat, 23 Mar 2019 at 17:49, Craig Treleaven wrote:
>>
>> I see no reason to report inactive ports.
>
> Neither do I. I would remove those as I already mentioned in an earlier email.

But in the spirit of lossless collection, those should be included and 
flagged as inactive, so that what to do with them can be decided later.

There are different reasons for inactive ports.  Sometimes they're just 
leftovers from upgrades without -u.  But sometimes the user is 
intentionally keeping inactive ports, to permit switching fairly quickly 
via activate/deactivate, either to keep multiple variants or to keep 
conflicting ports.

On Sun, 24 Mar 2019, Craig Treleaven wrote:

> I?m not familiar with the 2015 work.  ?port? now returns zero for 
> successful completion.  Have we considered having port set a return code 
> that indicates the general class of an unsuccessful operation?  For 
> example, we have 8 port phases defined (fetch through destroot).  We 
> could return -1 through -8 to indicate failure in a particular phase. 
> More to the point, we could return a specific value for failures such as 
> when active_variants determines that a required variant is not 
> installed.  Similarly, if the port is not supported on a particular OS 
> configuration another specific code could be returned.  I don?t 
> contribute to base but that would seem to be a minimally invasive 
> modification.

Speaking of return codes, it's not very helpful that "upgrade outdated" 
returns error status if nothing is outdated. :-)

Fred Wright