On Jul 17, 2007, at 14:42, Eloy Duran wrote: [snip]
I have now submitted a patch that adds universal support to the ruby port. http://trac.macosforge.org/projects/macports/ticket/12314
[snip]
I've submitted a patch which adds "universal_variant no" to all gem based ports. http://trac.macosforge.org/projects/macports/ticket/12317
I have also submitted a patch that adds "universal_variant no" to rb-rubygems. http://trac.macosforge.org/projects/macports/ticket/12318 (I accidentally marked it as a defect instead of an enhancement.)
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.
Now the last patch I have is the one for rubycocoa itself. But first I would like to now if it's allowed to change the name of the port? Because the name of the software is rubycocoa not cocoa....
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.
Also I saw today that building from a clean macports installation with the universal variant now breaks at the point where perl is being build (for autoconf?). I must have been sleeping last time I checked (about 2 weeks ago), but I could have sworn it didn't fail back then. But actually more important, perl doesn't build as a universal. So should I tell my users to tell port to build rubycocoa as a universal and expect it to break at the point of perl, then tell port to build perl as a non-universal and afterwards again tell port to build rubycocoa as a universal?? This doesn't really feel ok.....
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. 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.