Distro invades '/usr/local'.

I wouldn't class this as a valid bug as Clem is free to put files where ever he likes (unless he signed the FSH agreement with the Linux Foundation).

@ leigh123linux:
This is what Wikipedia has to say about it:
"Most Linux distributions follow the Filesystem Hierarchy Standard and declare it their own policy to maintain FHS compliance."

You could use the same logic to say that Clem can put distro files in /home/* directories because he didn't sign any agreement with the Linux Foundation.

I'll tell you how this is a problem. With the alert going out about the GHOST/glibc issue I did the following to check my glibc version:
vecna bin # apt list | grep glibc
vecna bin # apt list
apt
Usage: apt command [options]
       apt help command [options]

Commands:
autoclean - Erase old downloaded archive files
<snip.....description doesn't offer "list" as an option>
version - Show the installed version of a package
                        This apt has Super Cow Powers

So basically, this looks like /usr/local/bin/apt acts like 'apt-get'. (I looked, it isn't a link.)

When you "man apt" you get the proper man page, which includes the list command.

Turns out the "real" apt is in /usr/bin:
vecna bin # /usr/bin/apt list | grep glibc

WARNING: /usr/bin/apt does not have a stable CLI interface yet. Use with caution in scripts.

clisp-module-bindings-glibc/trusty 1:2.49-9ubuntu1 amd64
eglibc-source/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc-reference/trusty 2.19-0ubuntu1 all
vecna bin #

That's the behavior I expected.

This is on a mint 17 system:
vecna bin # cat /etc/issue
Linux Mint 17 Qiana \n \l
vecna bin # uname -a
Linux vecna 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
vecna bin #

This is how it works with ubuntu 14.04:
root@vance:~# cat /etc/issue
Ubuntu 14.04.1 LTS \n \l
root@vance:~# uname -a
Linux vance 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@vance:~# apt list | grep glibc

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

clisp-module-bindings-glibc/trusty 1:2.49-9ubuntu1 amd64
eglibc-source/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc-reference/trusty 2.19-0ubuntu1 all

So, in my mind, having to hunt around to find the proper apt, as shown by the man page on my system, is problem.

Another way that this is a problem: I just wound up here upon seeing /usr/local/bin/mint-md5sum, wondering if someone had managed to without me noticing it dump a compromised md5sum binary onto my system. I'm sure hardly anyone will have trouble coming up with reasons as to why that's not a valid problem. I am also sure that this should NOT be installed into /usr/local.

I've never heard of an "FSH agreement", and even if there were to exist such thing, the discussion of whether Clem signed it completely misses the point. One doesn't follow the FHS because of having signed some piece of paper, but because violating it invites all kinds of problems.

I can see what the perpetrator was trying to do, but it's misguided; the Debian Alternatives System specifically exists to offer a clean solution to this particular problem:
https://wiki.debian.org/DebianAlternatives
To me, this is a red flag regarding maintainer competence. Some years ago, I dumped Bodhi Linux over violating the FHS, and now I'll be parachuting out of Mint as soon as I can.

What the status of this? I agree with Rene and KennoVO this is unacceptable!