I fixed that. Don't forget to add yourself in the Cc line of every bug you submit, and also Cc the port maintainer, if there is one, so that they learn about the ticket's existence.
Thanks.
I think this is still an undefined area. It would be nice if we could just "svn mv rb-cocoa rb-rubycocoa" (if indeed consensus is that this is a good idea) but this would be bad for all users who already have rb-cocoa installed. They would not be informed that their port has been renamed and they would never know if there are any updates unless they later manually install rb-rubycocoa. In some past cases, port authors have kept the portfile under the old name and changed it in some way -- either so that it just outputs an error message advising the user to install the other port, or going so far as to automatically uninstall the old port and installing the new one. The latter seems like a good idea from a user's ease-of-use perspective but the implementation of this feature in those portfiles was deemed scary because MacPorts has no support for this. I think it would be beneficial for MacPorts to have portfile syntax to say that a port has been superseded by a different port. This way all ports like this could be handled identically. We could start with something very simple: a new keyword for portfiles: superseded_by rb-rubycocoa Anyone who tries to install this port gets a message that the port has been replaced by this other one. Anyone who already has the old port installed will see something in "port outdated", and if they try to "port upgrade" the port, they'll get a message advising them to uninstall the current port and install this new port. Then later, if we want, we can look into a process of automatically uninstalling the old port and installing the new one, but we don't need to think about that now.
That looks like a real good idea to me. Who should/will create this patch?
I think the simpler instructions for your users would be to install perl5.8 without the +universal variant, then install rubycocoa with the +universal variant.
I haven't checked it yet, but I thought that this might build dependencies fro ruby as non universal.
And, why perl again? autoconf requires perl5.8... what requires autoconf? Giving perl5.8 a functional +universal variant can be investigated separately. The port has no maintainer, however.
The ruby portfile uses autoconf, but I'm not sure if it's really needed. I will try this later on... I have added a new patch to http://trac.macosforge.org/projects/macports/ticket/12317 which will now add +universal to the default_variants if the ruby in ${prefix}/bin/ruby is a universal binary. Cheers, Eloy _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
