This bug is specific to the linux packaging of libreoffice, as delivered by TDF. Since version 4.4, libreoffice deb packages have started installing a libreoffice4.4 link in /usr/local/bin. Up to version 4.3, such link was installed in /usr/bin. Having packages installing stuff in /usr/local is a violation of the linux filesystem hierarchy standard (FHS), as well as the debian and ubuntu policy documents. It is also against the unix tradition of having a /usr/local hierarchy where the admin has the guarantee that no system functionality (e.g. packaging) will make any automatic modification. From the FHS, sec 4.9. 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. From debian lintian Debian lintian (package checker) has an explicit error condition for this, with severity "Serious": The package installs a file in /usr/local/... which is not allowed From debian policy Sec. 9.1.2 As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. [...] because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation Is there any reason why in the 4.4 branch the choice to move the libreoffice4.4 link from /usr/bin to /usr/local/bin was made? Can this change be reverted?
Yes, a Debian/Ubuntu provided package should not install in /usr/local and the do not. However, TDFs packages are NOT distro provided (and thus NOT "system software" as per FHS), are thus using /usr/local to prevent collisions with distro provided packages (which are "system software"). Closing INVALID, Thanks.
Some comments 1) Why cannot they simply conflict with the distro provided packages, which would be the most natural thing? Trying to install the TDF provided LibO without first removing all traces of the Debian/Ubuntu provided LibO is often the origin of weird problems anyway. This is probably particularly true when one tries to start a version and there is another one already running. Is there any reason or practical use case why the TDF LibO should be installable in parallel with the distribution one? To the best of my knowledge, no-one else who is providing packages does the same (e.g. you cannot install Mozilla's firefox in parallel with the distribution mozilla or Owncloud's Owncloud in parallel with the distribution provided one). 2) Anything that is packaged becomes in some sense system software, regardless of who provides it, as it becomes automanaged by system tools. Things start getting triggered automatically without the admin realizing it. 3) An admin may like to have in /usr/local/bin his/her own wrapper to libreoffice, or may have scripts verifying the integrity of anything that is installed there, messing with his/her own playground with packages is something that may work in 99% of cases and still cause gratuitous trouble in the remaining 1%. 4) I believe that the suggested approach to prevent collisions rather than polluting /usr/local/ is to install in opt (as you do) and have the post-installer script add a file to /etc/profile.d to update the system path so that what has just been installed can be found.
Investigated the matter a bit more. The general wisdom that I collected is that is that /usr/local/bin is for user programs not managed by the distribution package manager such as locally compiled packages that must be safe from modifications, overwriting and deletion when the package manager is invoked. If this is the expectation, the principle of least surprise strongly suggests not to break it. This regardless of whether the program is an official part of the distribution or not. And in fact, non-distribution packages, such as all packages in ubuntu ppas and software provided by third party vendors as packages tend not to pollute /usr/local. Also because when you accept the idea that it is OK for a packaged software to pullute it, it gets unclear where to stop. E.g.: if it is OK for a packaged software to put a link in /usr/local/bin, would it be OK also to put 100? and to put all its libs in /usr/local/lib? Furthermore, another reason for not having packages that install across /usr and /usr/local is that (though this is not extremely frequent) setups exists where the /usr and /opt trees are shared among multiple hosts, while the /usr/local tree is precisely local and as such not shared. On these setups, anything that installs across the shared and not-shared part ends up broken.