RubyCocoa 0.11.1

[Ryan Schmidt]

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.