Distro invades '/usr/local'.

Bug #1399934 reported by Manuel Iglesias Alonso
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Linux Mint
Confirmed
Undecided
Unassigned

Bug Description

1) Linux Mint 17.1 'Rebecca', Cinnamon 64-bit.
2) Problem is always there.
3) I found distro files in '/usr/local'.
4) I expected '/usr/local' to be the exclusive domain of the system administrator.
5) Problem is always there.

After updating from Cinnamon 17 to 17.1, I have noticed that the new version includes several files in '/usr/local/bin'. If I am not mistaken '/usr/local' should be reserved for the sole use of the system administrator. Here is an extract from Red Hat's 'Overview of File System Hierarchy Standard':
'The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.'

I have files of my own in '/usr/local' (it is a link to a directory in the '/home' partition in my system) which could be overwritten by the distro. I also control file execution precedence (by setting $PATH value) and my plans could be thwarted if there are files in '/usr/local' I am not aware of.

Distro files detected in '/usr/local':
/usr/local/bin/yelp
/usr/local/bin/gnome-help
/usr/local/bin/search
/usr/local/bin/pastebin
/usr/local/bin/mint-md5sum
/usr/local/bin/highlight
/usr/local/bin/apt

Revision history for this message
leigh123linux (leigh123linux-j) wrote :

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

Revision history for this message
Manuel Iglesias Alonso (glesialo) wrote :

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

Revision history for this message
Rich (richfranksjr) wrote :

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.

Vlad Orlov (monsta)
Changed in linuxmint:
status: New → Opinion
Revision history for this message
Rene Herman (rene.herman) wrote :

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.

KennoVO (kenno-xs4all)
Changed in linuxmint:
status: Opinion → Confirmed
Revision history for this message
KennoVO (kenno-xs4all) wrote :

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.

Revision history for this message
Christian Bourque (christian-bourque) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.