Re-do MacPorts after upgrading from Tiger to Leopard on PPC?

[Bradley Giesbrecht]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090314/6fe230f0/attachment.html>