user instructions - was ... mysql5 + php5 + apache2

[markd at macports.org]

>> I don't think this is not worth the effort.
>> if there were a way to provide instrictions, it would encourages
>> developer to write more messages I suppose.

Sure, but analogous to port developers making patches that they don't try
to send to upstream developers is a problem, making our own docs has some
pitfalls too since sometimes we are doing what the developers should have
(when it isn't stuff that is MacPorts specific).  And I'm a little more
pessimistic that creating a infrastructure will spur people to write more
hints and docs because it takes time, patience, and they need to be
updated once created.  But I'm in no way opposed to doing anything that
helps; I probably do more doc writing than any other port author.  I'm all
for anything doc related that helps that we can agree on as long as it is
efficient and sustainable.
>
>One option would be to simply hold back any message until all ports
>installed and output them afterwards. So all messages would be at the
>end of the log.
>
>Or, use some new target like print_message {}, but which would need to
>be stored in the registry after installation to be always available in
>the state as it was on install.

I like these types of things.
>
>For this rather long nedi help, I would prefer to put them into some
>file like /opt/local/share/doc/nedi/INSTALL.macports and just print a
>message that there is additional help in this file.

Yes, but if you want variables evaluated within the instructions, and I
do, then you end up doing reinplace on keywords so you add another file to
${files} and require more coding and probably some errors in the process. 
So now you've got to debug the instructional phase.  I prefer it either as
it is (ui_msg) or by adding a command that would crank out and evaluate
the ui_msg section on the fly after a port is installed.

Mark