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

[Bradley Giesbrecht]

On Mar 13, 2009, at 10:47 PM, Ryan Schmidt wrote:

> On Mar 13, 2009, at 11:17, Bradley Giesbrecht wrote:
>
>> port installed | sed '1d' | awk '{print $1$2}' > installed.txt
>> port -f uninstall installed
>> for item in $(cat installed.txt); do port install $item done
>
> On Mar 13, 2009, at 11:27, Bradley Giesbrecht wrote:
>
>> Whoops, need to remove +darwin_8.
>>
>> port installed | sed '1d' | sed 's|+darwin_[0-9]||g' | awk '{print  
>> $1$2}' > installed.txt
>
> It's a noble effort, but this will cause ports to be reinstalled in  
> alphabetical order, which is almost certainly not dependency order.
>
> For example, consider someone who has the ports mediawiki, php5  
> +apache2+mysql5, and mysql5 +server installed. mediawiki depends on  
> php5 and mysql5, and php5 +mysql5 depends on mysql5.
>
> mediawiki is alphabetically before php5 and mysql5 so your script  
> will install it first. MacPorts will go and build the dependencies  
> php5 and mysql5 with their default variants, meaning php5 will not  
> have mysql5 support, and mysql5 will not have its server startup item.
>
> Then later in the list you will come to mysql5 +server and ask  
> MacPorts to install it and it will go and build the whole thing  
> again, only it won't be able to activate mysql5 +server because  
> mysql5 with no variants is already active.
>
> Same for php5, which will already be active with its default  
> +apache2 variant so the new +apache2+mysql5 won't be able to be  
> activated.
>
>
> 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.

> There are other issues in MacPorts base that might be more important  
> to fix. But if you feel drawn to provide a solution for this issue  
> in MacPorts base, we could start by discussing how it might work and  
> what the command might be called.


If this can't be done in 30 minutes of hacking I'd say let it go. I  
won't be learning tcl to add this feature. Not this weekend at any rate.

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


//Brad