Handle Formula renames and deletions

[mxcl]

The git diff tells us what has been renamed. So we need to watch that and rename kegs and update symlinks. We need this for taps too.

The git diff tells us what has been deleted. So we need to watch that and look in Aliases to see if a new one is created and if so treat it as a "dupe" being deleted and do the above. Not for taps: taps don't have Aliases (yet).

When we can do this we need to delete one of

• lastfm_fplib and lastfmfpclient (dupes of each other).

When we can do this we need to rename:

• mosh -> mosh-scheme
• cmu-sphinxbase and cmu-pocketsphinx (remove the cmu prefix)
• yuicompressor -> yui-compressor or even just yui

This thread serves as official renames thread. Please research the Debian names also as this is the canonical naming DB.

[jacknagel]

Others that have come up in the past:

• beanstalk -> beanstalkd
• google-perftools -> gperftools
• offline-imap -> offlineimap
• objective-caml -> ocaml
• d-bus -> dbus

[Sharpie]

15776 is an example of why renames need to be fixed so we can use them when necessary.

A rename attempted in adee531 crashed brew update and had to be rolled back in bdaae65.

[sheerun]

Mosh should be renamed, totally

[goodell]

Another future rename for the list: mpich2 v1.5 --> mpich v3.0rc1. See #16298 for more info.

[winmillwill]

I don't think mining the git log is the right way to handle this. If we have a replaces method on Formula, then can't we just load any formula named in the array returned by that method? We throw an exception if formulae try to replace one another, then if nothing got thrown, we have an authoritative name for the keg, and we just bring the cellar inline with that.

To me this seems easier for everyone, because there's an obvious red flag in the review of new formulae (you think this replaces WHAT?) and a smoking gun when things break after the cut over. It should even be possible for brew doctor to see if the replacement relationship of recipes is in a sane state, and say what's wrong.

[jacknagel]

Hmm... well, we have to look at the diff anyway in order to learn the new names of renamed formulae. Otherwise we have to load every formula, which is very slow, and check their replaces method, and we'd have to do this on every brew update.

We'd also have to carry this replacement metadata indefinitely, whereas doing it via the diff requires no additional metadata.

because there's an obvious red flag in the review of new formulae (you think this replaces WHAT?)

I think that's handled well enough by the fact that file is being renamed ;)

I'm not totally opposed, but I'm definitely not ready to dismiss the diff-based solution.

[winmillwill]

True enough.

I looked at how Debian handles it: http://wiki.debian.org/Renaming_a_Package and aside from the artifice of dealing with the bigger, more sophisticated apt, the idea seems to be "make a dummy package that just depends on what the new name is, and migrate the logic to the new package".

In this way, brew update just guts, say offline-imap.rb so that it just says depends_on 'offlineimap' and the new recipe pops in, there's a new keg, and it's the responsibility of the new Formula to make sure that any conflicting configurations get cleared away. This should be just a matter of whether there are symlinks with the old name and deciding whether to persist them for backwards compatibility or not.

If we're worried about people's cellars getting bloated and crufty, it should be additionally possible to flag a recipe as a dummy so that brew doctor or similar can recommend deleting dummies that don't fulfill any dependencies.

Are there more gotchas I'm not seeing?

[ghost]

Could same mechanism that currently maps postgres to postresql be used ?

[Exocyst]

The formula mcrypt.rb installs libmcrypt, and should therefore be moved to libmcrypt.rb so that a proper formula for mcrypt (the command line executable mcrypt, that is) can be submitted. These changes would be inline with their debian counterparts. BTW, I have a working formula ready for the executable mcrypt.

[hkjels]

We've had to symlink yui for MacOs. yui-compressor is the name used on debian and ubuntu for sure.

[urdh]

Suggested rename (if/when #18910 is merged): watch -> procps visionmedia-watch -> watch

[jacknagel]

I don't think so, even debian has "watch" as a virtual package pointing to procps.

[Josh-Tilles]

plt-racket → racket

[nixpulvis]

+1 for plt-racket -> racket

[apakulov]

go-app-engine-32.rb -> app-engine-go-32.rb go-app-engine-64.rb -> app-engine-go-64.rb app-engine-java-sdk.rb -> app-engine-java.rb google-app-engine.rb -> app-engine-python.rb

[sjackman]

Homebrew/science/glimmer3 → Homebrew/science/glimmer See Homebrew/Homebrew-science#809

[dakcarto]

geogit -> geogig

See: #34814

[guoxiao]

stash-cli => atlassian-cli see #40909

[MikeMcQuaid]

Support for this has been implemented in #41006. I'm going to leave this issue open until we've migrated more of the mentioned formulae in here to new names.

[jhass]

That's great news, can we have crystal renamed to crystal_generator then, to reduce confusion with the much more popular Crystal language? See the discussion in #40530.

Are there plans for any process around requesting renames, especially from non-maintainers?

[MikeMcQuaid]

@jhass We'll be considering each rename on a case-by-case basis. You can request renames but obviously we can't make any promises either way right now.

[jhass]

Well, consider the above a request then.

[wesbland]

As mentioned way above and in a closed ticket (#16298), mpich2 --> mpich.

[MikeMcQuaid]

Closing this now that this is implemented and we've migrated a few formulae without end-user issues. There are a few open PRs for renames but if there isn't one open for your chosen rename: please submit a pull request following the documentation in https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Rename-A-Formula.md and format in e.g. https://github.com/Homebrew/homebrew/issues/14374. Thanks @vladshablinsky!