RubyCocoa 0.11.1

[Eloy Duran]

> 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