On Mar 14, 2009, at 11:50, Bradley Giesbrecht wrote:
On Mar 13, 2009, at 10:47 PM, Ryan Schmidt wrote:
You would have to replicate the MacPorts dependency engine in your
script if you wanted to handle this correctly. But then why not
implement it inside MacPorts itself. Which you would be welcome to
do. But it's not something users need to do all that often.
It makes testing things like the perl5 port easier in my opinion.
If I can make changes to a Portfile, uninstall everything that
might touch it and then reinstall everything I'm more likely to do
more thorough testing.
Perhaps, but we shouldn't be encouraging people to nuke their entire
MacPorts installation just to test new ports. We should have better
ways. For example trace mode was intended to help.
I'd be happy with logging install, upgrade and uninstall commands
that resulted in file system changes.
This isn't a big deal. It seems to me that there are probably six
or so places in the port code that would need to have a function
call added and then write or use an existing function or two for
formating and writing the output. If it's more complicated then
this then let it go unless you want this too.
u=user driven command
d=depends driven command
/opt/local/var/log/port.log:
u,timestamp,command+args
d,timestamp,command+args
d,timestamp,command+args
u,timestamp,command+args
We do have the existing logging proposal here:
http://trac.macports.org/wiki/LoggingProposal
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
