Errors should probably come after notes?

Mojca Miklavec mojca at
Fri Apr 15 11:42:52 PDT 2016

On 15 April 2016 at 19:47, Ryan Schmidt wrote:
>> On Apr 8, 2016, at 4:23 PM, Mojca Miklavec wrote:
>>> That's a tough question -- you wouldn't want users to miss the notes,
>>> either.
>> Sure. But notes can get pages long and when doing a mere upgrade they
>> are often irrelevant ("if you want to make this version of X your
>> default, run port select ..."). The error would be a few lines at most
>> (not counting the "port -v ..." output of course, but just the lines
>> that say where to look for long and how to report a problem).
> Ideally, ports should not print irrelevant notes. For example, if the notes are telling you about how to copy a sample config file to make changes, the port might be improved to not print those notes if the sample config file had already been copied.

I have no idea how to implement this. For example, buildbot-slave
prints notes that ask you to copy a sample configuration file to the
"real" one, where two files may not hold the same name. So basically
every slave needs a file with a different name. This means that's it's
almost impossible to figure out whether the file has already been
copied or not. And even if it has already been copied, the user might
want to add another instance / a new file.

> Not sure what to do about the "port select" notes though. You could not print them if a version has already been selected, but users who deliberately do not select one would continue to see irrelevant notes.

Indeed. There might be users who already selected one particular
version of a port, forgot how they did it and might like to change it
again to the new version (let's say when python 3.6 gets released).
And there might be users who deliberately don't want to use "port
select" for a particular port.

I don't see any reasonable way to solve this automatically (other than
perhaps deciding not to print notes on upgrades, but ...).

All I wanted to say that I would find it important/convenient to at
least repeat the fact that a port installation has failed after the


More information about the macports-dev mailing list