Bug Hunting Session
Bug 59513 - Debian-provided packages: unversioned link to start libreoffice is missing
Summary: Debian-provided packages: unversioned link to start libreoffice is missing
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.0.1 rc
Hardware: Other Linux (All)
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Desktop-Integration Installer-Linux
  Show dependency treegraph
 
Reported: 2013-01-17 11:07 UTC by sergio.callegari
Modified: 2019-06-09 03:45 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Debian-provided menu file for LibO Base (for inspiration) (229 bytes, text/plain)
2013-02-07 16:25 UTC, Lionel Elie Mamane
Details
Debian-provided menu entries for all applications (for inspiration) (1.45 KB, text/plain)
2013-02-07 16:27 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2013-01-17 11:07:39 UTC
Problem description:

In the deb packages, the libreofficeX.Y and libreofficeX.Y-printeradmin executable get symbolic links in /usr/bin only if the debian-menus package is installed.

However, these links have nothing to do with the debian menus.

Since the debian-menus package from libreoffice 4RC1 and libreoffice3.6 are mutually incompatible, this means that one can either have libreoffice3.6 or libreoffice4.0 in the standard path, but not both, even if libreoffice3.6 and libreoffice4RC1 appear to be simultaneously installable.

Furthermore a simple /usr/bin/libreoffice link (with no version appended, maybe managed via the alternatives mechanism) is missing. This means that any script invoking libreoffice must be manually updated at every libreoffice update.


              
Operating System: Ubuntu
Version: 4.0.0.1 rc
Comment 1 Björn Michaelsen 2013-01-18 16:10:28 UTC
Is this with the distro package or with upstream packages?
Comment 2 sergio.callegari 2013-01-18 18:57:55 UTC
upstream
Comment 3 Joel Madero 2013-01-23 18:03:53 UTC
Bjoern - looking for guidance on this one still. Thanks!
Comment 4 Michael Meeks 2013-02-07 15:45:41 UTC
Fridrich, any chance you can take a look :-)
Comment 5 Lionel Elie Mamane 2013-02-07 16:17:53 UTC
(In reply to comment #0)

> Since the debian-menus package from libreoffice 4RC1 and libreoffice3.6 are
> mutually incompatible, (...)

IMO, *that* is the real problem. There is no good reason for them to conflict.

Here's what should happen, file per file:

FILE DEBIAN/control:

now has:

 Provides: libreoffice-desktop-integration, libreoffice-unbundled
 Conflicts: libreoffice-desktop-integration, libreoffice-debian-menus, libreoffice-bundled
 Replaces: libreoffice-desktop-integration, libreoffice-debian-menus

should have (example for package lodev4.0, should be replaced by base package name):

 Provides: libreoffice-desktop-integration, lodev4.0-desktop-integration, libreoffice-unbundled
 Conflicts: libreoffice-debian-menus, libreoffice-bundled
 Replaces: libreoffice-desktop-integration, libreoffice-debian-menus

OR (if necessary for some reason, I don't think so)

 Provides: libreoffice-desktop-integration, lodev4.0-desktop-integration, libreoffice-unbundled
 Conflicts: lodev4.0-desktop-integration, libreoffice-debian-menus, libreoffice-bundled
 Replaces: libreoffice-desktop-integration, libreoffice-debian-menus

I don't know what "libreoffice-bundled", "libreoffice-unbundled" and "libreoffice-debian-menus" are about, so for now don't touch them. I have a hunch that at least libreoffice-debian-menus should be removed.


FILE usr/lib/menu/lodev-debian-menus: rename to usr/lib/menu/lodev4.0-debian-menus (that is the VERSIONED name)

In this way, there will be menu entries for EACH libreoffice version installed.
Comment 6 Lionel Elie Mamane 2013-02-07 16:24:46 UTC
(In reply to comment #5)
> (In reply to comment #0)
> FILE usr/lib/menu/lodev-debian-menus: rename to
> usr/lib/menu/lodev4.0-debian-menus (that is the VERSIONED name)

Actually, that file should go to usr/share/menu/, not usr/lib/menu/

And it uses outdated sections. The sections list is at http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html

Basically Apps -> Applications, and then the substructure has changed.

I'd say just copy from the Debian-provided packages...
Comment 7 Lionel Elie Mamane 2013-02-07 16:25:34 UTC
Created attachment 74362 [details]
Debian-provided menu file for LibO Base (for inspiration)
Comment 8 Lionel Elie Mamane 2013-02-07 16:27:22 UTC
Created attachment 74363 [details]
Debian-provided menu entries for all applications (for inspiration)
Comment 9 Lionel Elie Mamane 2013-02-07 16:35:58 UTC
(In reply to comment #0)

> Furthermore a simple /usr/bin/libreoffice link (with no version appended,
> maybe managed via the alternatives mechanism) is missing. This means that
> any script invoking libreoffice must be manually updated at every
> libreoffice update.

This would make them not coinstallable with the Debian-provided packages. If the Debian-provided packages switch to an alternatives-managed symlink, then yes, we can participate in that schema. René, would you be willing to make /usr/bin/libreoffice (and friends?) an alternatives-managed symlink?

Failing that, all we can do is in our .debs, would maybe have a separate package "lodev4.0-make-default" which would install the symlink and in its control file:

Provides: libreoffice-default-version
Conflicts: libreoffice-common, libreoffice-default-version
Depends: lodev4.0

Then one and exactly one of these "make this version the default" (or the Debian-provided package) can be installed at the same time, and this one will have the /usr/bin/libreoffice symlink.
Comment 10 Joel Madero 2013-02-07 16:46:12 UTC
I'm going to go ahead and mark this one as NEW as it seems like it's been confirmed by Lionel
Comment 11 Rene Engelhard 2013-02-07 16:48:12 UTC
> Debian-provided packages switch to an alternatives-managed symlink, then yes,
> we can participate in that schema. René, would you be willing to make
> /usr/bin/libreoffice (and friends?) an alternatives-managed symlink?

So that people install the "packages" from upstream site, change the alternative, forget about that and report bugs they get when invoking "libreoffice" to the debian packages?

I don't think we should do that.
Comment 12 Rene Engelhard 2013-02-07 16:52:00 UTC
or imagine a new or changed version and version-mix between upstream and Debian packages. It will break on one of them.

That's also the reason why I said "no" to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695916
Comment 13 Rene Engelhard 2013-02-07 16:52:41 UTC
That said, I don't mind if upstream packages and Debian package conflict, afair they even do right now :-)
Comment 14 sergio.callegari 2013-02-07 17:09:39 UTC
Explanation about the missing unversioned /usr/bin/libreoffice link is totally convincing for me. I would avoid the lodev4.0-make-default package if it is meant to hold just one link. It is easier to create a single symlink in /usr/local/bin than to install a package.

But I still would move the versioned link such as /usr/bin/libreoffice4.0 away from the debian-menu packages. In the end you might want that even if you do not want to have libreoffice in the menus (e.g. because you are using it in headless mode for document format conversion).
Comment 15 QA Administrators 2015-02-19 15:50:43 UTC Comment hidden (obsolete)
Comment 16 sergio.callegari 2015-02-20 13:01:19 UTC
The bug is still present as of 4.4.0.3 and has *worsened*. In the following point 1 is new, while the other two points are confirmed from the past.

1) A symbolic link, in /usr/local/bin/libreoffice4.4 is created by the libreoffice4.4-debian-menus.  This is a very evident violation of the
debian policy. Deb 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 (Debian policy manual Section 9.1.2 Site-specific programs). It is also in violation of the Linux Filesystem Hierachy Standard, that states "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*". Note that up to version 4.3, libreoffice was putting a link in /usr/bin, which was OK with the policy.

2) The link to libreoffice4.4 should likely not be managed/created by the libreoffice4.4-debian-menus package as it is. In fact, the debian-menus package should have to do with the /desktop integration/. The link to have libreoffice on the path should be provided even if one choses not to install the desktop integration, because it has to do with the ability to start the program at all which is needed even without desktop integration (e.g. in installations where libreoffice is used as a server for document conversion with no desktop integration at all).

3) The system lacks a libreoffice executable (namely, something like /usr/bin/libreoffice, rather than /usr/bin/libreoffice4.4). This should be present and managed by the debian alternatives system. Otherwise, when one upgrades libreoffice (e.g. from 4.3 to 4.4) all the scripts that need to call libreoffice break and need to be manually updated (or a manually created link needs manual updating).  If the alternative system is not feasible (due to chance of breaking if debian decides to implement a similar scheme for its own deb files of libreoffice), the idea in #9 of having a package to provide the default version to invoke would be a step forward. Another possibility would be to use the alternative mechanism with name "libreoffice-default" not to conflict with debian. But, please, provide something to call that is stable between upgrades.
Comment 17 Björn Michaelsen 2015-02-20 13:07:47 UTC
TBH, I dont think it is a high priority goal of the generic upstream TDF packages to conform to details of various distro policies. There are nicely packaged versions of LibreOffice provided by Debian, Ubuntu etc. for that.

Nonetheless, your patches wrt this are of course welcome (if they not violently break policies of other distros).
Comment 18 sergio.callegari 2015-02-20 15:43:36 UTC
AFAIK, packages should not interfer with /usr/local in all distros conforming to FHS and all major distros conform to FHS (debian, redhat as rhel and fedora, centos, ubuntu, suse...). Furthermore, FHS takes this from the traditional unix filesystem layout (see http://en.wikipedia.org/wiki/Unix_filesystem).
So, it is not so much a matter of conforming to the details of various distro policies but a matter of not breaking the expectations of system administrators.

The patch that I propose is to revert the 4.4 change that put put the libreoffice link in /usr/local/bin rather than in /usr/bin.
Comment 19 sergio.callegari 2015-03-12 10:41:34 UTC
Created a new bug about the fact that the libreoffice4.4 link is placed in /usr/local by the deb installer.

See Bug 89963

Hence, this bug can remain as just the original enhancement request for providing a way to call libreoffice that remains stable across major updates (e.g. libreoffice or libreoffice-current), so that scripts do not break on updates.
Comment 20 Björn Michaelsen 2015-03-12 11:13:33 UTC
Just quickly: Whatever patch is provided for this, no TDF package outside the unfortunate named "debian-menus" package should install anything in the the proper FHS locations (apart from the /opt or /usr/local locations). TDFs packages are not "system software" (while Debians and Ubuntus packages are) and thus should explicitly stay out of locations reserved for "system software" (which is most).

debian-menus is the sole exception to this, breaking FHS for convenience of using TDFs builds.
Comment 21 sergio.callegari 2015-03-12 15:55:51 UTC
Downgrading to the distro provided packages.
Unless this is of some interest to someone else, please close.