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
Is this with the distro package or with upstream packages?
upstream
Bjoern - looking for guidance on this one still. Thanks!
Fridrich, any chance you can take a look :-)
(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.
(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...
Created attachment 74362 [details] Debian-provided menu file for LibO Base (for inspiration)
Created attachment 74363 [details] Debian-provided menu entries for all applications (for inspiration)
(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.
I'm going to go ahead and mark this one as NEW as it seems like it's been confirmed by Lionel
> 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.
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
That said, I don't mind if upstream packages and Debian package conflict, afair they even do right now :-)
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).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
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.
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).
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.
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.
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.
Downgrading to the distro provided packages. Unless this is of some interest to someone else, please close.