Will ruby19 replace ruby?

[Ryan Schmidt]

On Dec 25, 2008, at 18:51, Neil wrote:

>>> 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

If the old-name portfile and the new-name portfile both try to  
install the same files, this will cause a conflict and MacPorts will  
not allow both to be installed at the same time.

> 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

We've had previous discussions about renaming py-* ports to py24-*  
for consistency and eventually decided against it because it would be  
a lot of work since MacPorts does not have any feature to help you  
rename ports or to indicate that one port has been superseded by  
another. I'm not even sure if a workable method was ever proposed.  
Consult the archives if you're interested in the whole discussion. I  
believe it would be a better use of time to first implement a port  
renaming / port superseding feature in MacPorts base, and only once  
that has been incorporated into a released version of MacPorts think  
about mass renaming of ports. Such a feature would be welcome in  
MacPorts base anyway, because we occasionally have the situation that  
software changes names and we have to rename a portfile, or sometimes  
a developer commits a new port for software that we already had a  
port for, and this goes unnoticed for some time, and later we have to  
clean it up.