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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
