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
