Will ruby19 replace ruby?

Neil kngspook at gmail.com
Thu Dec 25 16:51:08 PST 2008


On Thu, Dec 25, 2008 at 3:24 AM, C. Florian Ebeling
<florian.ebeling at gmail.com> wrote:
> On Thu, Dec 25, 2008 at 12:06 PM, Neil <kngspook at gmail.com> wrote:
>> On Thu, Dec 25, 2008 at 2:59 AM, C. Florian Ebeling
>> <florian.ebeling at gmail.com> wrote:
>>> On Thu, Dec 25, 2008 at 11:30 AM, Neil <kngspook at gmail.com> wrote:
>>>> After ruby19 is stable, will it replace ruby?
>>>
>>> since 1.9 has a slightly, but incompatibly changed syntax, I don't
>>> think that would be a good idea. I find other dynamic languages
>>> being present in parallel in several versions and though we do
>>> the same with ruby. E.g we have php4/php5,
>>> python{21,22,23,24,25,26,30}, perl{5,5.8,5.10},
>>> so it seems reasonable to do the same with ruby.
>>>
>>
>> I don't think it would be a good idea either, but I wasn't sure:
>> there's no 'perl' or 'python' ports, but there's a 'ruby'.
>>
>> So then for consistency's sake, there should be some renames; for example:
>> ruby -> ruby18
>> py-* -> py24-* (or to their respective dep, all the ones I've seen are
>> depending on python24)
>> rb-* -> ruby18-* (perhaps)
>
> sounds like a lot of work to me for a small gain. you would probably need
> an empty "ruby" port with a sole "ruby18" dependency to avoid breaking
> all existing ports and installation, and then explain all this to puzzeled
> users. and probably the same for all ruby/rb-* ports. So quite some migration
> phase.
>
> but if somebody was willing to drive such an effort I wouldn't opposed
> it. we should still probably get quite detailed reasoning about all the
> implications for various scenarios and explaintions why it doesn't
> break things, before starting.

Well, if there's some consensus that it's a good long-term move, and
the maintainers don't mind my mucking around, I'm happy to (attempt)
the actual portfile changes.

I think the steps would be:
1. copy the old portfiles into new ones with just the names changed
2. make the old ones depend on the new ones
3. grep (with a bit more finesse, obviously) the tree to have other
ports that depend on the old ones changed over to the new ones
4. wait a while
5. eventually remove the old ones

> PS. Please use Reply-All in list discussions, otherwise mails don't make
> it to the list.
My bad, intended to, sorry...


More information about the macports-dev mailing list