On Mar 14, 2009, at 10:06 AM, Ryan Schmidt wrote:
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.
That sounds good to me.
Since it's possible that the next perl5.8 port revision will move man
and modules to new locations I wanted to test it on a clean install
and also as an upgrade of an existing system. I want to verify that on
the upgrade of perl5.8 the p5 files that have been -f installed are
not removed when the perl5.8 port is upgraded.
I also would like to be able to put my system back to it's previous
state after each test.
How would you suggest I do this? I'd be very happy to learn a better
way.
This doesn't need to occupy our time. I'm just offering ideas and
features I would like. Things are working great as is.
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
+1
Nice to able to parse data into db for analysis.
I don't know that this happens a lot but if I am installing a port
that has deps on another port and I intend to build that other port a
different way knowing why and when the port was built helps me get my
build order correct.
gentoo emerge has -p (pretend) which reports what emerge would do and
in what order without actually doing anything. This can be useful.
//Brad
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
