Colorize hardlinks in ls output?

How can I colorize hardlinks myself? Turns out on an old Ubuntu 10.04 I have, this happens by default (same .bashrc and .profile in use), whereas on the newer Ubuntu 12.04 it doesn't.

This is the output on Ubuntu 10.04 (the one I desire):

And this is the output on Ubuntu 12.04:

The relevant file is .vimrc, however, .viminfo is an ordinary file with link count 1, in contrast to the hardlinked .vimrc.

Of course the fact that GNU coreutils uses texinfo pages instead of man pages doesn't make things easier. I found this here, but it doesn't refer to the case I am looking for.

TL;DR: how to achieve coloring hardlinked (as in: link count > 1) files the way I like in various Ubuntu versions.

Do this:

LS_COLORS="mh=44;37" ls -l

And you may edit your ~/.profile to change LS_COLORS accordingly.

Background

This feature was enabled as default in 2008 has been disabled by default in 2009. Somehow the freeze for Ubuntu 10.04 was exactly in between those moments.

Using the Git repository of coreutils I see that the commit to revert automatic colourization has been in since version 7.5:

git tag --contains 0df338f6719ec2bcf1e1dea2d8b12dc66daf8a1e
v7.5
v7.6
[...]

In versions before 7.1 there seems no upstream maintained support for this:

git tag --contains 1e48b1fee5fa2ad2d1802771eafbfcddb38a24cb
v7.1
v7.2
[...]

The source file multihardlink.sh, lead me to the exact LS_COLORS value to enable it again.

You may want to reopen LP Bug #123423.

Based on gertvdijk's answer, I came up with the following snippet, which suits my needs:

if [[ -e "/etc/debian_version" ]] && type dircolors > /dev/null 2>&1; then
    command dircolors|command grep -q 'hl=' && export LS_COLORS="ln=01;36:hl=00;36"
    command dircolors|command grep -q 'mh=' && export LS_COLORS="ln=01;36:mh=00;36"
fi

Edit: I actually had to rewrite the snippet (see edit history).

Turns out that ls swallows the error output concerning LS_COLORS when piping it. At least I couldn't grep for it, neither with 2>&1 nor without. Hence the changes. We check for dircolors to be available. If it is, it's expected to output a snippet of shell code (Bourne shell compatible by default) that contains the defaults for the various recognized file types. So we check for hl= or mh= respectively in the output of dircolors. This way we can detect which is expected by ls and export LS_COLORS accordingly. It may be safer to grep for :hl= and :mh= respectively to rule out the possibility for file extensions ending in hl or mh and matching our condition.

The above colors are light cyan on black for soft links and a darker cyan on default black for hard links.

You can vary the top-level condition, of course. I am currently only setting it on Debian/Ubuntu, because I have no time to test it on older RHEL/CentOS systems at the moment.

NB: the invocations via command are to work around potential aliases/functions with the same names as the tools we try to use here.